9: How Much SOA Do I Need?
The author concedes that SOA is a niche tool, and that companies should carefully consider factors that may undermine the potential value of SOA for their enterprise. Said another way, there are instances in which SOA is the wrong tool for the job, and an attempt to use it will have negative consequences that may poison the reputation of the technology and prejudice decision-makers against its use in future projects, even if it may be appropriate.
SOA IS NOT A PANACEA
As with most emerging technologies, there's a great deal of hype about SOA, and it's billed as a magical tonic that will cure all conditions. This is never true.
The author identifies a handful of scenarios that should be "yellow flags" when considering SOA: modifications to high performance or real-time systems, systems that have a high throughput, intricate B2B transaction systems, batch processing, data warehouses, and tight coupling with monolithic data systems. In each case, there are significant dangers and drawbacks, so proceed with extreme caution.
Another area of caution is the assumption that any "rule" is universal. The author gives the analogy of the way that people learning English often overextend grammar rules, such as assuming that every verb can be cast in past tense by adding "ed" when, in reality, there are a fairly large number of irregular verb tenses. Likewise, analysts have the tendency to overlook irregular situations when determining the rules that drive the functionality of services, either generalizing or failing to consider all instances, and the results can be damaging.
The author also refers to the "goldilocks principle," which implies the need for the degree of implementation to be "just right." Too little service orientation, and the solution is not flexible or reusable. Too much, and the amount of effort required to convert a large number existing processes to services will cause SOA to be an expensive and time-consuming option.
SELECTIVE SOA METHODOLOGY
The principle of "Selective SOA" entails evaluating a project proposal to determine which elements can logically and feasibly be built based on services.
(EN: The author places a trademark symbol on "Selective SOA" the first time it is used, but either does not indicate the owner of that mark, or I have overlooked it.)
The process begins with a "bottom-up analysis" that takes a systems-based approach: examining the IT resources that will be required for a project and determining if there are any technical benefits to converting them to services
Next, a "top-down analysis" is done, beginning with the business processes that the system is being implemented to support and determining if the user of services can make human processes more efficient or effective.
Finally, a value-based analysis is done to determine if implementing services in the present project can create better value for the organization (increased revenue, decreased costs, improved service to customers, etc.) both in the context of the project and the larger view of the enterprise.
The Pareto principle is then applied as a method of drawing a reasonable "line," based on the theory that 20% of the proposed improvements will create 80% of the total value of SOA, and those are the ones that it makes the most sense to pursue.