Thanks to the hype generated by the analyst community and followed by the vendors, every customer Enterprise Architect has gotten a directive from the above to create an SOA strategy. Often the directive is not a result of the realization of the need for SOA but a result of a manager/architect attending an analyst conference. Often customers ask me about the need for creating an SOA strategy for their company, where to start, and how to go about doing it. SOA strategies born this way are bound to fail because they are not created out of necessity (or perceived necessity). Instead, SOA must be the product of many years’ worth of well-orchestrated and need driven strategies rather than an accidental fluke.

Before an architect spends too much time in creating an SOA strategy, the following high-level motivating factors of SOA need to be understood:

• SOA for  revenue generation (SOA-R)
• SOA for business enablement (SOA-B)

I am guilty of complicating this already complicated business with two more acronyms, but I think it necessary to differentiate the thought processes centered on the above strategies.

The primary objective of SOA-R is to create new revenue streams to compliment the exiting top line in an effort to bolster the shareholder’s value. Some examples are Microsoft Live initiative, Google and Amazon web services. SOA-R is readily aligned with business and the probability of this succeeding as an SOA implementation (from the architecture perspective) is very high. However, its success as a revenue contributor depends on the soundness of the business strategy and the contemporary market forces.

Following are some of the characteristics of SOA-R:

• Implicit business alignment, because often the initiative comes from the business
• Readily available business sponsorship, as it seen as the direct visible contributor to the top-line
• Less stressful organizational dynamics from the political maneuvering perspective because SOA strategy is very cohesive and it is often confined to a fewer number of departments
• Stringent quality control, because it directly affects the market share
• Rigorous interoperability through standards-based implementation, as syndication of these services is a potential revenue generator.
• Streamlined operational management and support infrastructure results in higher customer satisfaction
• Well defined processes for billing and collections are the key success factors. They directly determine the viability of the strategy as a long term top-line contributor.
• Associated with profit centers

The primary objective of SOA-B is to streamline the information systems of an enterprise by elimination of redundancy through effective reuse of loosely coupled business process abstractions (equivalent IT implementations). SOA-B focuses in enabling the business and is generally associated with cost centers. It is the SOA type that we often hear about in the IT industry. The probability of the success of SOA-B is mixed at best when compared to SOA-R, as SOA-B requires a lot more rigor in governance and spans a relatively large number of political territories.

While the creation of these business process abstractions across a large enterprise (that can be used to compose applications and services) is a wonderful concept, it is also fraught with perils (given the current state of the practices and tools). Large enterprises are not static and change all the time through mergers/acquisitions, adapting themselves to changing business conditions (by changing processes as result), and creating information systems at the speed of business. The creation of shared resources (services/applications), if not done properly, can create chaos in a large organization, because it will create mega service dependency networks. These dependency networks, even though they are loosely coupled from the technology perspective , semantic dependencies can cause havoc when the underlying semantics of the services were to change. SOA-B suffers a lot more than SOA-R because its scope is far broader than SOA-R.

Following are some of the characteristics of SOA-B:

• Business alignment has to be a conscious effort and depends on the nature of the IT organization. In a decentralized IT (with small IT organizations attached to business units and operate autonomously), implicit business alignment is attained through the structure of the organization. But the story is different for centralized IT. It requires conscious and rigorous processes to make sure that priorities are aligned with business because the central organization is constantly bombarded with project requests. This is not only true for SOA services but for all IT projects as well.
• Business sponsorship is a critical success factor. It does not come easy here because the benefits of the SOA-B are often intangible and a multi-year strategic effort. Also, SOA-B is seen by the business as an IT strategy and not directly related to the running of the day-to-day business. No business stakeholder is going to give you a million dollars to go buy a best-of- the- breed XML gateway (or what have you) for implementing SOA. The architect has to contend with what resources he has at hand, show the value of the SOA as seen by the business, and progressively get their mindshare.
• IT Sponsorship also does not come easily for SOA-B. Often CIOs work closely with business executives and tend to side with the business when making IT strategic decisions.  As budgets are shrinking, CIOs are often asked to do more with less and they tend to earmark dollars for IT projects that are tangible. One way of winning the IT executives is to use the existing resources (work from your garage if you have to!) and show the value of SOA through demonstrable implementation. That should start winning the CIO’s mindshare.
• Large technology and semantic dependency networks will be a huge risk because tools are not mature enough to show the bigger picture of these networks from both perspectives. Vendors are finally getting their acts together in making SOA implementation tools ready for the industrial strength service development. However, development tools alone cannot guarantee success here. We need tools that help with governance, operational management, service level agreements (SLA), change management, provisioning, etc. This is true for both SOA-R and SOA-B, but the scope of SOA-B makes the tools a bigger critical success factor.
• Implementation of a Service Registry using either ebXML or UDDI. Even though UDDI is complex, it is widely supported; thus, it’s recommended to go with UDDI.  If UDDI is too complex to start with, even a simple custom web site for services is a minimum. The promise of SOA, to eliminate redundancy and create applications by composing from the existing services, is only possible if there is a directory of these services that can be discovered by the other organizations. It is absolutely necessary to formulate a registry strategy before even putting the first service in production.
• Chargeback infrastructure is a strategic necessity but is not mandatory in the beginning. For centralized IT infrastructures, this may be easy but it is a challenge for decentralized infrastructures. SOA services have to be architected and implemented with the usage based chargeback in mind. And with the chargeback comes the SLA factor. Services have to be built with optimal instrumentation so that the tools have enough insight into the services during operations to enforce SLA policies.
• Political minefield – be aware of  political sensitivities and territorial claims before asking your counterpart in another department to throw away his vertically integrated order processing system and use your order processing services. An architect is not going to like this, even if the directive comes from his management; he will try to poke as many artificial holes as he can ranging from insufficient service contracts through production operational inadequacies.
• Stringent quality control
• Associated with cost centers

Some more SOA thoughts in future blogs.

Regards,

hanuk