SOA services still too constrained by applications they represent
It almost seemed as if the whole bottom-up versus top-down argument for SOA had been settled, once and for all. The best approach from now on would be bottom-up, with some middle-out, or something like that. None of this "big bang" stuff. Business units will build focused, ROI-generating projects which eventually percolate to their neighbors across the enterprise. Then a critical mass is reached, as more and more people would buy into the growing SOA along the way. The bottom-uppers won this round.
JP Morgenthal, one who never buys into conventional wisdom at face value, questions this concept, however. He says SOA sustainability comes from "analyzing from the top down, not the bottom-up as bottom-up results in tactical solutions that do not conform to the needs of the business over time."
Aw, JP, say it isn't so. But he explains why many companies are under the illusion that all you need is loose coupling, and you're on the road to SOAtown:
"Implementing an SOA design such that real loose-coupling is achieved and that a service does not share a common bond with any other service down to its roots in persistence and all the way up to its consumers, using today's technology mix, is complex, clumsy and fraught with sandtraps."
The problem, JP says, is that SOA works best this way when services are stateless -- meaning the service "retains no knowledge of the consumer prior to or post usage and has no assumed context of the consumer." However, he says, most of the business applications services will surface "are rich in user context and assumptions of their environment. Reporting, security and governance are excellent examples of features that are hindered by moving to a loosely-coupled services architecture and, if implemented in a way that leans too heavily toward one particular application's requirements, limits the service's ability to operate in multiple application contexts."
JP also questions the strong emphasis on reuse. The challenge, he says, is that the more specialized a service is, the less reusable it is. This means the above-mentioned services that are anchored to specific applications may not work well in reuse scenarios. Thus, the success of reuse is limited to plain-vanilla services -- not a compelling vision for transformation.