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:
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:
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:
Some more SOA thoughts in future blogs.