Phil Windley makes a case about SOA and complexity. I'll buy the conclusion, but the argument needs more realism. Here goes...
First, no one's IT architecture looks like the first figure. That figure is too neat. The real picture is somewhere between the first and the second, but the integration lines are supported by an evolution of technologies from previous-generation message queues to file transfer to re-entering data by hand from one application to another (or worse, by hand from a print out).
Second, a future SOA architecture is unlikely to look like the second figure, for several reasons. One reason Phil makes indirectly: that picture is so complex as to be unmaintainable. So while *someone's* IT architecture may end up this bad, the typical architecture almost certainly won't.
Other reasons that figure is unrealistic: business processes provide a natural organizing force for large grained services. I have trouble believing the architecture of the future will be made of hundreds of interacting components without some large grained (logical, if not physical) hubs of service organized by purchasing, inventory, manufacturing, sales, general ledger, etc.
A third reason I have not seen mentioned much in the past year, but I believe will hold even as the business cycle improves. That reason is vendor consolidation, two forms of it. On the IT side, even Phil's argument points out that an SOA benefits from organizing forces. One of those forces is for an IT architecture to drive toward fewer vendors supplying products into the architecture. On the vendor side, well, vendors will want to be on those select lists, and so will continue to merge and make overall sense of the resulting product strategy.
On to the three problems Phil enumerates for an SOA...
First, "No one team understands or controls all the moving parts". But that is true today without a doubt.
Second, "Change management is more complex". Maybe. But almost by definition a useful SOA has to evolve toward fully embracing the parameters of being "loosely coupled". Change management is complex today, to a large degree because there has been little enterprise architectural guidance and pieces thrown together have resulted from little attention to "loose coupling" principles.
Third, "Separation of concerns is more difficult". Unlikely, for a few reasons. Concurrent, even ahead, of the movement to an SOA, is the movement of IT organizations themselves to an Enterprise Architecture alignment. More attention than in the past is being paid to enterprise concerns prior to deployment, as far ahead as the capability roadmap, the project concept, or at least the project planning stages. The people who support the IT architecture, pay for it, and even those who design it, are sensitive already to the problems inherent in such a picture and are already showing signs of addressing "separation of concerns" at the enterprise level through architecture and through budget (Enterprise Program Management). A challenge is to find enough balance between avoiding constant interaction and indirect impacts of minimizing communication. (Plug goes here for new collaboration tools like Wikis and RSS to lower the effort of finding "just enough communication".)
Lastly, a default argument could be made that a large movement toward an SOA is inherently dependent on SOA vendors addressing these problems effectively. This leads to somewhat of a Catch-22, but we can expect the usual curve of early adopters to begin working out the kinks.
I don't believe many of these problems will be addressed by "web service intermediaries" per se. Although the infrastructure is still immature, the real problems for the enterprise are at the boundary where the services architecture meets the business architecture. The real problems of heading toward a world of rich services is how to get them to play at the business level. How do you keep them agreeing on a correct chart of values, a correctpart and product hierarchy, roles and responsibilities, up-to-date with engineering change notices, etc.
These are not insurmountable. To reiterate I believe the movement toward an SOA will be preceeded by a movement to realign IT for the enterprise architecture and go hand in hand with vendor and product consolidation, and less custom development. Without these steps, then yes, the future looks unmanageably complex. *With* these steps the future is still complex because the changes will be gradual and IT will continue to deal with the as-is and the to-be concurrently. But at least there is hope if the SOA products mature and rational principles are in place for their adoption.
