Today SOA remains largely hype. The promise of modular, reusable services connected seamlessly into larger applications, while great in theory, has, by some estimates, reached maybe 20 percent of its potential. It is time to ask why and what to do about it.

Imagine a technology architect faced with solving real business challenges who attends an introductory briefing on the concepts of a service-oriented architecture. Our architect, who must then apply these concepts to applications that solve real business problems, identifies five shortcomings and asks for a response.

1. “But what about the data management!”

A service-oriented architecture does nothing to solve one of the major issues in application development—the provisioning and maintenance of data—and in fact can make it highly complicated. Unless accounted for programmatically or via some intelligent middleware design, data is simply passed in and out of services via XML. While at a micro level, this works well, when services are strung along into the processes that comprise an application, dependencies emerge which can significantly reduce the value of loosely coupled services. For example, in an application that processes invoices with four sequential services, it is likely that each service creates data for the next service (approvals, inventory checks, etc.). Step 4 is then highly dependent on the way data is processed in each of the previous steps so if a change to one of those results in different data, such as a change in the format of the shipping address, step 4 also needs to be changed. Likewise if a step 2a is inserted, steps 3 and 4 will likely need to be modified. This results in cascading maintenance effort.

2. “But the processes my services support aren't that simple!”

Imagine a process that is not strictly sequential. For example, to process an order we need four approvals (via four different services) which can occur in any order but they must all occur before the fifth service creates the shipping manifest. Because services typically work synchronously (you call a service and wait for a response) and because they only have information from prior steps, it is difficult to model and execute a non-sequential process.

3. “But my services don't let me respond to activity I can't predict or model!”

How do I model and arrange services into processes I can’t predict in advance? For example, disaster recovery operations where, as any relief worker will tell you, the sequence of events is not planned in advance but rather made up on the fly based on events on the ground (transportation, equipment status, location of supplies, etc.).