SOA in Action

Who pays for SOA, at least initially? Should IT pay? Should the business unit that originally commissioned the service bear the initial development costs? What motivation is there for a business unit that spent $500,000 to build a set of services to share it freely across the rest of the enterprise? How do you prod managers that already have budgets for new development to start reusing someone else's services -- and thus put them in a position of having unspent finds? (Human nature -- no one likes to have future budgets slashed.)

I have put these questions to industry experts, and have received many different answers. Some say SOA is a special case that needs to be nutured off to the side, at least initially. Others say SOA should be funded and supported in the same manner as any other IT project.

Forrester analyst Ken Vollmer advocates introducing SOA to the organization through an unofficial "skunkworks" effort, with some seed funding from the CIO's office. As the skunkworks achieves some successes and cost savings with reusable services, word will get out across the enterprise.

Belinda Hayes, vice president with Systinet-Mercury-HP, says she has seen SOA funding models work best when they are structured along the same lines as existing IT projects. For, example, if a company has a standard IT chargeback mechanism, this should be applied to SOA-based services as well.

Dan Foody, vice president with Progress Software, says not to worry too much about the funding issue. He is inclined to believe that funding issues will diminish as the SOA grows and its value becomes apparent. "Yes, your first projects will be more expensive as people get up that learning curve. But there's nothing fundamental about SOA that makes it more expensive."

A new survey commissioned by BEA Systems sheds some light on SOA funding, at least among large enterprises. The survey of 150 corporations found that close to six out of ten SOA projects were funded by the business unit itself. Only in 19% of the cases did the funding come out of IT's hide. (A copy of the survey is available from BEA here.)

Even more intriguing is the fact that 22% of these corporations reported having dedicated SOA budgets to fund their projects.

Not that there isn't plent of money being poured into SOA. The survey found that almost half of the organizations had spent $1 million or more already on their current SOA projects -- even though most only have two to three projects underway. In addition, at least 40% expect to spend another million on SOA over the next 12 months. In most cases, SOA represents less than 20% of the IT budgets of these organizations.

Where is all the money going? A majority of SOA funding, 54%, is going to training and skills acquisition. Another 40% of SOA spending is spent on infrastructure, mainly enterprise service buses, security, and data services.

If these large organizations set an example -- as they typically do -- then there seems to be recognition coming from on high that SOA is critical to business success going forward, and that there are ways to tie funding to the business units that stand to gain the most, at least initially. Of course, these organizations always have the budgets to throw a few mill at new projects. But small to medium-size businesses also need to seek ways to tie SOA funding to line of business benefits.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

The vendors may not like to hear this, but product selection may be the simplest part of SOA development and deployment.

I've been following Todd Biske's "Outside the Box" blog posts for some time now, and was pleasantly surprised to see that Todd very nicely articulated the goals of this SOA in Action blogsite. Todd, an enterprise architect with MomentumSI, described our mission as "to focus on the practitioners of SOA, not the vendors marketing it. So much of IT communication in the public domain is dominated by the vendors, not by the practitioners."

Often, the complexities in the post-product selection phase are understated, Todd continues. Vendors "have some very smart people and put out some useful information, but I tend to think that product selection isn’t what is holding companies back from a successful SOA adoption. It’s like a big chess game. Each enterprise represents a pattern on the chess board. We must recognize the patterns in front of us and make appropriate decisions to move toward success."

In fact, Todd adds, the factors involved in IT are far more complicated than chess. "Wouldn’t it be great if we knew certain players in the enterprise could only move one space at a time, diagonally, or in an L? After all, governance is about generating desired behavior. If the roles and capabilities are not well communicated, desired behavior will be difficult to achieve."

Couldn't agree more, Todd.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Adapters -- who needs them? Who wants them? The goal of SOA is to simplify, simplify, simplify. However, SOA can also work the other way, and actually introduce a new layer of complexity to systems already choking on complexity. How can you ensure that your service-oriented architecture makes things simpler, and not evolve into a spaghetti-oriented architecture?

George Scott, CTO of Cast Iron Systems, proposes one approach -- integration appliances. In a new post at ebizQ, Scott explains how appliances can force complexity out of the service layer, "integration appliances allow more resource to be applied at the business layer where the ultimate payback for the company lives."

What does Scott mean by "appliances"? Typically, these are preformatted bundles of hardware and firmware that reside on networks, and can be placed wherever they are needed and easily managed and upgraded.

By its very nature, SOA is all about transparency and opposed to the deployment of "black box" solutions within the infrastructure. However, the new generation of integration appliances have their own transparency, are built entirely on standards, and may alleviate much of the performance strain services will put on servers and storage systems.

Integration appliances are the most logical solution for data integration, Scott said, as "they are often the best way to integrate various directory services and can be used to construct the services exposed to the workflow/BPM layer." The three best places to introduce appliances into SOA include the following:

As an alternative to adapters in data integration projects. "By avoiding the complexity of manual process integration, appliances can also avoid the bane of every integration project: Adapters. Adapters are hard to maintain, hard to upgrade, expensive and, by definition, every type of adapter is a thing unto itself. With recent improvements in standards, they are usually unnecessary. In simple cases, direct data integration suffices. In more complex cases, the service can often be built directly on the target applications. Solutions that use adapters don’t scale."
.
Directory services. "Directories for entitlements, service discovery, etc., need to present their information in a single format through a unified interface. Though simple in theory, this is almost never the way real corporate directories look and act. This is really a data integration problem in disguise. As such, an appliance can be a very good solution for normalizing directory access."

Service presentation. "A properly designed data integration appliance is not suitable for manual workflow, but is capable of holding and representing enough state (via BPEL, for instance) to serve as an intermediary between applications and the workflow/BPM layer. Since the most common place from which to access a directory is the service layer, it is possible to build a uniform and easily managed infrastructure that abstracts all but the services themselves away from the developer of business process."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

"Business process management could be implemented without SOA, because both capabilities have been available for some time. But implementations of BPM without the SOA foundation take longer. There's more ongoing maintenance and support costs are higher, and therefore ROI is delayed. An analogy of doing BPM without an SOA foundation would be like a juggler with one hand tied behind his back. He can still do some juggling, but not as effectively and not as fast as it could be."

In his keynote address for the SOA in Action online conference, Forrester's Ken Vollmer connected the dots between BPM and SOA. Only lately have the two approaches been converging, and Vollmer said the time is ripe to begin pursuing combined BPM-SOA approaches to increase the flexibility of business processes. (Replay is available here.)

"SOA provides a more standards-based approach of doing BPM," Vollmer said in his address. First, the notations that come out of the initial modeling process can be exported into standards such as business process execution language (BPEL), "which then, in the form of XML, can be executed inside the execution engine," he explained. Then, foundational standards such as SOAP, WSDL and UDDI "support the interaction between the business applications and the modeling tools. If these standards did not exist, the model-driven development in the BPM tools would not be possible."

Vollmer observes that while BPM suites were originally developed to support integration and process improvements, "once these tools were installed inside of organizations, it quickly became clear that they were very good for supporting service oriented architecture, and composite application development."

Another emerging link between SOA and BPM is SOA repositories, "which will reside in the back of BPM tools," Vollmer predicted. Such repositories "will be able to store a number of interfaces or artifacts related to applications, interface specifications and code, processing policies and security issues, process flows, and semantic data links -- all stored inside a repository or more likely in a set of federated repositories."

These repositories can be employed to "provide the business analyst with a view of the modeling stage of the things they need to see, the service developer with a separate role of the things they need to see, and a service architect view. In effect, the SOA repository will provide different views for different roles in the development cycle, all coordinated through the service repository. This will help keep all of the different roles in sync as to what's going on, because a change made in one view will be reflected in other views as appropriate."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

There's been no shortage of confusion in the industry about the role and makeup of the enterprise service bus, or ESB. Just about every vendor has a product they call an ESB, but there are questions around their scalability and interoperability.

In this panel discussion at ebizQ's recent SOA in Action online conference, Progress Software's Dave Chappell and Cape Clear's David Clarke sought to clear up some of the confusion around ESBs. (Replay is available here.)

"Unfortunately it's the IT departments who are trying understand and evaluate ESBs that suffer the most from the current lack of clarity of a definition of ESB in the marketplace," said Chappell, who defines an ESB as a platform "used to connect mediate and control the interactions between a diverse set of applications that are exposed through the bus using service level interfaces."

ESBs should be light and rapidly deployable, Chappell added. Ideally, an ESB "shouldn't require the heavy footprint of monolithic integration brokers or application servers deployed repeatedly in order to provide the proper infrastructure support," he said. "Capable of being deployed broadly across the extended enterprise with minimal intrusion without requiring a large staff to install and manage over time."

Clark noted that ESBs are an evolving technology, and that it currently is "the best way to implement SOA." In addition, he added, "we consider ESB the principal container for business logic. This is the next generation application server."

ESBs will continue to change as approaches to SOA change, he added. "As the level of capability and sophistication and understanding of how you can implement SOA increases or evolves, the definition of ESB and how it should rightly behave will also evolve."

Both Clarke and Chappell emphasize, however, that ESBs are not mandatory for SOA development -- but it really helps to have one. "What we're finding is that organizations are approaching SOA through a variety of ways today," Chappell said. "Some are using ESBs, some are using Web services capabilities that came with their application servers, or with their ERP systems, some are using Web services toolkits."

However, effective SOAs are difficult to build, and attempting to manage a jumble of point-to-point Web services can become unwieldy. "An ESB provides a common backbone upon which you build your SOA," Chappell continued. ESBs "provide a layer of abstraction between SOA objects.. This common backbone can provide a unified, enterprise-wide approach to ensuring quality of service issues, such as guarantee of service requests, and a common means of applying common security and solution for fault tolerance and high availability within a service infrastructure."

"Using an ESB prevents you from having to spend time in low-level plumbing details directly into your services," Chappell said.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

"Service-oriented architecture not really rocket science. Yes, it may be a little more complicated than past architectures, but people don't have to do it perfectly to succeed and still be able to met the needs of the company. You just have to do it well enough."

In his keynote address for the SOA in Action online conference, Gartner's Roy Schulte described the evolution of SOA within organizations, starting as a relatively simple engagement involving a small, non-mission-critical application, growing to complex organisms requiring involvement from all parts of the enterprise. (Replay is available here.)

In the pilot stage, a single pain point may be addressed, typically involving a small application, handling fewer than less than 10,000 transactions a day. The good news at this stage is that no special purchases need to be made for SOA. "When doing an architecture on this scale, you don't need to buy any special technology," Schulte said. "You can use technology purchased for other purposes."

In the next stage, companies will typically buy their first piece of SOA technology, which is typically an enterprise service bus, Schulte continued. "The scale is still generally small," he added, but there is a noticeable increase in complexity. "At this time the applications may be in the same business unit, but there may be multiple application application systems. You may be looking at multiple steps in a business process, rather than just using SOA within one step of the process."

It is at the third and fourth growth stages that SOA finally explodes on the enterprise scene, Schulte continued. The total number of services may grow past 500, and the " number of service calls or messages per day may reach up to close to a million," he said. Also, in a large enterprise, there may be at least 20 to 100 developers building SOA applications. "At this point, the approach to service oriented architecture "must become notably more systematic, processes must become more repeatable, and systematic tools.. are going to be needed," he said.

Ultimately, the goal is to make SOA as the "default architecture" within organizations. "That is, all new applications will be built using service oriented architecture," he said. However, he added, "very few companies are at this stage today. They may be there in five to eight years."

While the initial pilots and projects can be accomplished within the confines of the IT department, as the SOA grows and adds services, the need for business management support will increase as well. "Once you start spreading service oriented architecture, you will become visible in some cases beyond the IT department to the heads of business units, whose applications are being migrated to service oriented architecture. At this point, you need support from the chief information officer. There should be support all the way to the CEO and CFO."

Schulte also said that the nature of SOA is evolving, from a "conversational" process between service providers and consumer to a more "interactive" event-driven architecture. Typically, SOA has been set up as a "series of messages that go back and forth between the service consumer and provider," he explained."In an interactive SOA, the consumer is more in control. The order in which things are done is controlled by the consumer at each step."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

SOA is a journey with many steps and many challenges. A new report in CIO Insight, however, does a good job of narrowing down the fundamentals to five key decision points in any enterprise SOA project. These points are based on the recommendations of CIOs and systems architects who have already built their first generation of SOA:

1) Retool the IT Department: Developers and IT professionals need to be retrained in SOA ways, and tech departments may need to be re-organized. "The services approach revolves around the creation of reusable software components—services—as opposed to monolithic applications. Developers schooled in traditional practices will need to learn to break down coding into smaller pieces."

Additional thoughts: The CIO Insight article does not mention incentives, but developers and IT professionals may need to be incentivized to move to reusable services -- in many cases, they are paid to generate code and monolithic applications, not to cut down and reuse services created and maintained by another part of the enterprise.

2) Establish an Oversight Group to Get Results: "An organization with hundreds (or thousands) of developers needs a common development approach to maintain consistency and interoperability among services. Developers in far-flung business units need to know what services exist. And reuse, as a policy, needs enforcement to make it a reality. A dedicated architecture group can make those things happen."

The old joke is that if you don't want something done, give it to a committee. However, SOA will not succeed with input and buy-in from across the enterprise. An oversight group -- comprised of both line-of-business managers and IT managers -- is the very core of SOA governance. There are many names for this type of body -- "Center of Excellence," "Governance Board," and "Steering Committee" are but a few of the names for such a group. But IT can't go it alone

3) Catalog Services to Enable Reuse: "As an organization grows its services portfolio, it will need a formal mechanism for keeping track of its software assets. SOA adopters should maintain a catalog of services [or registry] that developers can consult to learn what services exist, and avoid duplication."

Perhaps the greatest challenge in deploying SOA is helping business analysts or line-of-business managers understand what services are already available that can be reused. A registry provides such visibility of an enterprise's SOA assets and other artifacts associated with the services.

4) Monitor Performance: "Once services go live, organizations need to keep tabs on them." Adopt services-management software that can monitor the behavior of services after they are designed, tested and deployed. Services-management tools take into account, for example, the reuse factor and the dependencies among services reuse creates. A change to one service will affect every application that makes use of it."

Once the SOA message begins to percolate across the enterprise, more applications may be connecting -- and disconnecting -- from these services with little or no notice. This can create performance challenges if not monitored.

5) Coordinate IT and the Business: SOA adopters "should make sure their IT departments and lines of business are talking. The services approach calls for close collaboration between technologists and the business side of the house. In order to really have a service-oriented architecture, you need to understand what the business wants to achieve."

Opening up IT-business communication is easier said than done. As much as possible, this needs to be baked into corporate governance. See point #2 -- an oversight team can help foster much of the communication needed to make sure the services being built and deployed.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Yes, tomorrow is the day the learning begins -- ebizQ's SOA in Action conference.

I'll be moderating a couple of sessions at this week's "SOA in Action" conference, which starts tomorrow and lasts through Thursday. Elizabeth Book observed that I'm 'almost inexplicably' cool about moderating the panels, but that's because it's going to be a lot of fun. And, among other industry luminaries, Elizabeth notes that Dave Chappell of Progress Software, the guy who wrote the book on ESBs, is leading a panel discussion on ESBs. (And I thought "Enterprise Service Buses" were those things that took you around the Microsoft Redmond campus.)

Other luminaries joining us include Gartner's Roy Schulte, Forrester's Ken Vollmer, and ebizQ's Beth Gold-Bernstein.

On Wednesday, I'll be joining Jim Garcia of Enporion and Jared Rodriguez of Skyway Software in a discussion of how Enporion was able to employ an incremental approach to build an SOA that made its services accessible to outside partners. Then on Thursday, I'll be joining Software AG's John Fitzgerald for a presentation on "Managing the SOA Lifecycle."

We hope to see you there!

Here's a schedule of events for this week's SOA in Action online event:

Nov 15 at 10:30am - 11:45am EST
Keynote - Meeting the Challenges of SOA Adoption
Speaker: Roy Schulte,Gartner

Nov 15 at 12:00pm - 12:45pm EST
Integration-as-a-Service (IaaS): Driving Business Value through
Speaker: Andrew Dent,Hubspan

Nov 15 at 1:00pm - 1:45pm EST
Enporion Eliminates IT Backlog Via SOA
Speakers: Jim Garcia, Jared Rodriguez,Skyway Software

Nov 15 at 2:00pm - 3:00pm EST
Panel Discussion - Understanding ESBs
Speakers: Dave Chappell, Vice President and Chief Technology Evangelist, Progress Software

Nov 16 at 10:30am - 11:45am EST
Keynote - What Is The Relationship Between BPM and SOA and Why Should You Care?
Speaker: Ken Vollmer,Forrester Research

Nov 16 at 12:00PM-12:45pm EST Building an Effective Integration Competency Center
Speaker: Rajeshwer Subramanian,Ohio Bureau of Worker' Compensation (BWC)

Nov 16 at 1:00PM-1:45pm EST
Managing the SOA Lifecycle
Speaker: John Fitzgerald, Product Marketing Manager,Software AG

Nov 16 at 2:00pm - 3:00pm EST
Panel Discussion: SOA Governance
Speakers:
Mike Gero, Director of product management, Progress Software Corporation
Christopher Crowhurst, Vice President, Technology, Thomson Web
James McGovern, Enterprise Architect, The Hartford

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

What is driving organizations to move into SOA these days? John Michelsen, founder and chief scientist for iTKO Software, says there are three types of SOA clients:

I recently had the chance to talk with ohn Michelsen, founder and chief scientist for iTKO Software, who said SOA implementers tended to fall into three groups. (The podcast is available here.)

1) Large financial institutions and logistics companies convinced “that they’re already fully SOA and are embracing some of the newer ideas in an evolutionary rather than revolutionary way.”

2) Others who have “renewed their efforts and their investment -- and they’ve brought the business side into that conversation, which is the difference between success and failure.”

3) Those convinced, “‘OK, I’ve got to get into this, and I’ve been reading the books that say, ‘SOA or fail,’ so I should do my part in it as well.’”

What are the major obstacles Michelsen sees to SOA implementations? First, there's the complications that arise when organizations attempt to interconnect systems that were working just fine on their own. Second are the issues that arise when service providers are on different lifecycles than service consumers. "There's always some kind of wrinkle to the high and lofty goals we have," Michelsen said.

“Systems that ran on their own just fine, once connected, start creating issues. Secondly, we’re depending upon each other and the partners, but they’re not on the same lifecycle,” Michelsen adds. “You might be an application developer within a company and I build services that you reuse. I have unintended consequences every time I change my services on you, and you have very little control, organizationally or politically over my lifecycle,” he notes.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

More grist for the "start small" vs. "bring in the enterprise" debate around SOA launches: A new report in CIO quotes end-users at a recent conference as urging that SOA efforts begin modestly.

Russell Rodrigue, senior vice president of business technology planning at TD Banknorth, told attendees at an AMR conference that the SOA journey should begin with a single step: "Start small. Pick a project that’s manageable and well-defined and that you have influence over." The bank adopted SOA to deal with integration with systems of acquired banks. The bank employed WebMethods technology to get newly SOA-enabled systems up and running within days' time.

Not everyone agrees that SOA should start on such a small scale, though. I've heard small pilot projects referred to as "lunchroom Web services," since they may not be addressing processes that are of great significance to the enterprise at large. Indeed, a case can be made for treating SOA with the same commitment, discipline, and governance as an enterprise mainframe project.

But those with the wallets in organizations, the C-level executives, need to be educated on the why’s of SOA. They’re not going to open up their wallets too widely if they don’t understand what it can deliver. Rapid successes with a limited handful of select services can speak volumes.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

"We’ve reached a point of maturity in the IT industry where we’ve pretty much automated everything. We need to take a look back and see what’s happened, examine the carnage or whatever happened in the hurry-up phase and see what needs to be fixed."

-Eric Newcomer, CTO of IONA Technologies

As part of our InfoWorld SOA Executive Forum series, I had the chance to speak with Eric Newcomer, an influential voice in the Web services and SOA worlds. (The podcast is available for download here.)

Eric, who first cut his teeth in the CORBA world in the 1990s, has seen it all by now -- the tangled messes of point solutions for every perceived problem, all expensive, and all ensnared across countless incompatible silos in enterprises.

SOA can help unravel these complex, overbuilt Spaghetti-Oriented Architectures, he says. But only if enterprises take a fresh new approach to the problem. After three decades of spending on IT "without really knowing how that spend contributed to the bottom line or overall business strategy, companies now want a scientific approach to calculating the cost of reuse and allowing multiple clients to access the same service or backends via service abstraction," Eric notes.

In the past, "hurry-up phase" of automation, decisions were decentralized around the technologies used and how they were run and staffed, rather than around the entire enterprise architecture.

SOA involves "realigning all those old boundaries, changing how projects are done and supervised," Eric says. "Nobody really needs a lot more features and functions; everybody's paid for a lot of software over the past decade they don't even use -- and nobody can do that again."

Instead, companies "need an incremental, cost-effective way to insert some minimal technology into the current environment that helps service-enable the investments they've already made over the past few decades."

The key is to be able to "reduce the upfront costs of getting started with SOA and allowing people to build up their infrastructure in a good distributed way as they build up their project," Eric says ."Companies are expecting their IT departments to adopt something such as SOA within the current budget envelope. Companies need to implement SOA incrementally, in a step-by-step, economically controlled fashion, so that their investments in software to enable their services are keeping pace with their ability to spend."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

At this year's InfoWorld's SOA Executive Forum, which is taking place this week in New York, no one is debating the merits of going to SOA. Rather, the tone of this season's gathering is, 'SOA is a reality at most companies. Now, how do we maximize the value of these implementations?'

I had the opportunity to attend Tuesday's proceedings. The first day's session was kicked off by AT&T's Rich Erickson, who described how the telecom giant has seen $40 million in "very real savings" as a result of its five-year evolution to SOA. At the core of the SOA are up to 75 reusable services and interfaces backed up by a mic of ESBs, integration brokers, and interop approaches.

Erickson noted that like many large, diverse organizations, AT&T faced considerable resistance to its Web services and SOA efforts. After a couple of years of struggle, the defining moment came when Erickson's team gained executive support from AT&T's senior VP in charge of systems engineering, who issued a "still-famous" memo, which stated, bluntly (and paraphrased): "Thou shalt use Web services," and "If you don't use Web services, you'll get fired."

While Erickson doubts such extreme punishment would have occurred, it very effectively got the message through to AT&T's far-flung development departments. "There's no substitute for strong executive support," he said. "There was a sea change after that memo."

Another sea change took place when Erickson's team recognized that it was not being effective in promoting SOA adoption, because they were meeting with departments too late in the process -- close to their application test phase. "It was already baked," he recounted. "We began meeting with them at design time instead. Before that, SOA was just a middleware strategy."

As described by BEA's Bret Dixon in the follow-up keynote, there has been a change in tone over the past year when it comes to SOA: "We're not seeing people debating whether to go with SOA or not -- we're now seeing people go full force into it."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

On the SOA in Action page, you will see a series of podcasts I recently conducted with technology leaders from seven SOA vendors as part of this week's InfoWorld Executive Forum. With the help of Gian Trotta -- who wrote up and posted the interviews -- we have painted a picture of the state of SOA in 2006.

Over the coming days, I will provide some snapshots and links to the interviews. Today, we start with Dan Foody, CTO of Progress Software, who talks about connecting SOA with all the essential "ilities" enterprises need to worry about -- reliability, scalability, manageability, flexibility -- and most importantly -- agility. (The podcast available for download here.)

What does it take to deliver agility through SOA? "What I hear over and over again is that SOA has nothing to do with technology," Foody said. "It’s truly organizational shifts that are required in the move to SOA. How do you incentivize people to want to reuse services? How do you get people in the IT organization to think about what the business cares about? How do you get them to think about information and business processes rather than the underlying technological infrastructure?"

SOA is not "thinking about ‘how does my database, my middleware, my portal tier, my app tier work?' It’s about inventory, fulfillment, ordering, and whatever those business functions are for the organization. That’s a major shift for many organizations in how they’re structured and how they think about how they build their organizations."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

There's a lot riding on SOA management. "Used correctly, SOA management can facilitate the cost effective deployment of new business relationships, the efficient use of existing IT investments and can measure the real value to the organization of SOA itself," observes fellow ebizQ blogger Ronan Bradley.

But how do you achieve such expansive management? Traditionally, managing technology has meant the monitoring of connectivity and associated quality of service, Ronan points out. However, as organizations move to SOA, things get more complex. Management needs to include information and business processes built on top of the technology levels of the middleware stack.

Ronan identifies key aspects of SOA management:

Registry: "As the core artifacts in SOA are of course the service definitions, it is essential that these are published with all the additional descriptions and definitions of modes of use required for successful utilization by consumers."

Identity: There are dedicated Identity management products for handling the maintenance and distribution of identities from inside and outside of the enterprise, and these must in turn integrate into the SOA management framework.

Lifecycle management: "In an environment with an expectation of change and the devolution of responsibility to make those changes, lifecycle management becomes crucial: How are new services rolled out? How are old services retired? How do you track the consumers of a given version of a given service?"

Security: "Supporting multiple security models reflecting the differing security needs within a department, across departments and out to suppliers and clients."

Service level agreements: SLAs are "important for both the supplier and consumer of the service: How much processing power is being used? How long does my request take to be completed?" Technology-driven metrics need to move beyond fault detection and "translate into the business domain."

Beyond technical infrastructure, SOA management has the capability to "provide a flexible infrastructure to ease the deployment of a new business relationship which can require everything from new identities, new security models to new business processes," Ronan states.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (1)

Web 2.0 is seen as a consumer-driven set of technologies, encompassing mashups such as Google Maps, Wikis, and social networks. However, Web 2.0 is coming to the enterprise soon, and will become a larger part of service-oriented architecture than we can currently imagine.

In a new ebizQ Webinar, David Mitchell Smith, VP at Gartner, and Christopher Crummey of IBM's software group provided their perspectives on what Web 2.0 means to the enterprise. (Archived Webinar is available to ebizQ members here.)

Smith illustrated the disruptive power of Web 2.0 with this statement: "A product that costs hundreds of millions of dollars and took 15 years to develop and refine and roll out has its guts copied by a four-person company, who make the same application available at the click of a mouse." Smith was referring to Microsoft Word 2007, and its new online competitor, Writely, now a part of Google.

Both Smith and Crummey pointed out that there is considerable convergence between Web 2.0 and service-oriented architecture taking place as well. For example, Smith said the concept of a "mashup" -- in which specific pieces of functionality are combined within a single presentation -- is the same as that of a composite application used in SOA. "We're starting to see a real blurring between the concept of composite applications and mashups," he pointed out.

Indeed, service-oriented business applications are similar to the Web 2.0 functionality offered through Websites. "The similarity is that we have programmatic access as well as other kinds of access to functionality that has previously been closed or locked up and only accessed in certain ways," Smith said.

However, there are also notable differences between Web 2.0 and SOA, Smith added. While SOA composite applications are tied to service level agreements that assure uptime, enterprise mashups from Web 2.0 applications typically don't carry SLAs. "In the Web 2.0 world, there are some things that have not been that well thought out yet," he cautions.

Another important differences is in the role of the business in technology deployments. Namely, while SOA needs to have business drivers before the technology is determined, Smith urges that Web 2.0 projects be undertaken with or without business input. "You should not wait to do the business requirements first," he said. "There's no reason to not start adopting some of these technologies right away. Some of these technologies are things you can take advantage of without going full force into changing how you do your business."

IBM's Crummey described how IBM has been fusing its own Web 2.0 approaches with its SOA. At the heart of the initiative is an enterprise portal that serves as a delivery platform. The portal "embeds Web 2.0 technology and weaves it into the fabric of the portal," he said. "We use portal to front-end our SOA architecture. SOA is very similar to portal. SOA is about reuse, SOA is about components, SOA is about reassembling components to add greater value and time to value. That's exactly what the portal is doing for us at IBM. It enables us to reassemble components in ways that weren't thought of before, and be able to provide value very quickly."

Smith points out that Web 2.0 in the enterprise will be surfaced as a "Web platform," or a virtual abstraction of an underlying infrastructure. "It's not a standalone platform, something you buy and stick in the box in the back room," he said. "It is virtual. It is separated often by a network, typically the Internet. It can be hosted, can be distributed and usually is. It's not just a client platform or a server platform, but a distributed one."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Lately, there's been plenty of discussion and debate in both the blogosphere and on the trade show circuit around how quickly, and whether, SOA delivers value to the business. Many pundits, including myself, say that most SOA gains have been focused on IT optimization, and pure business benefits will come along later.

As SOA efforts progress, more accounts are emerging of how SOA can go right to the bottom line of a business. In fact, ebizQ's latest SOA survey found that business reasons are the main drivers to SOA efforts. Almost two out of respondents, 64 percent, said that the goal of their SOA effort is to "increase business agility," followed by "IT reuse" at 57 percent. "Business process optimization" followed with 55 percent, and another 44 percent sought the advantages of composite application development. "That led us to the conclusion that SOA adoption is really business driven, it is not just for reducing IT costs," Beth Gold-Bernstein pointed out. "SOA is more of a business initiative than an IT initiative."

An impressive example of the SOA-business link is Harley-Davidson, which was able to surpass its older, more rigid technology to a more flexible model that is in tune with the business. I originally posted an account of Harley-Davidson's story a few months back over at my ZDNet blog, but it's such a great example of SOA-business interaction that it's worth repeating here. The motorcycle giant is a shining example of the plan it-build it-manage it credo we talk about here at ebizQ's SOA in Action site.

Harley-Davidson's CIO, Jim Haney, explained how how loose coupling can go right to the business bottom line. In the spring riding season, for example, people begin to wander into Harley’s showrooms with visions of riding on the open road, but haven't quite made up their minds if they would actually go through with buying a motorcycle.

Harley-Davidson is well aware of these dreamers, and actually has marketing programs for turning showroom fantasies into realities. "Those programs are targeted to get those people that are dreaming about motorcycles to actually purchase one," Haney said. "We want to put together a good financial package to entice and incite people to get into the sport."

At first, Harley’s credit and loan origination process wasn't quite up to the task. The problem was that the company's financial services applications were tightly coupled with each other, Haney explained. Making a change in one program meant having to go in and change countless other applications as well. "The way our systems are very tightly coupled, being very rigid from how they are architected, if we made one change to one of those systems that supports one of those processes, we basically have to touch all of the systems."

That's a lot of work and time lost when a new marketing program is designed. Harley's answer was to break it all up. "We actually busted apart all of those systems, and put the SOA with WebSphere in the middle of all that," Haney said. "We loosely coupled these things. Our goal is to be able to change any one of those systems. If we see key indicators in the industry, we want to very quickly put different marketing programs in place, and not have to go and touch and test every single system."

There you have it -- business agility, the ultimate feat of SOA. Again, Harley is more the exception than the rule, but as SOA progresses beyond the confines of IT, the business will discover new ways to reach markets -- and not be hampered by archaic or hard-to-budge systems. "We can change an application, and do it quickly," said Haney. "We can be a lot more responsive to the business, which helps us sell motorcycles — the business we’re in."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)