Phil Windley writes about SOA and complexity:
Service oriented architectures (SOAs) are about reuse. The goal of a service-oriented architecture is to build applications using modules that (1) look like network services, (2) are potentially very far away and (3) perhaps owned by someone else. There are some significant benefits to be had including reduced hardware expenses, fewer systems to operate and maintain, and better software reuse. All of these benefits come at the expense of significantly increased complexity.
There are basically three problems:
No one team understands or controls all the moving parts. Problems have much wider impact. As the second schematic shows, there is a big ripple effect for service failures, increased latency, security lapses, and so on.
Change management is more complex. Parts need to be added, upgraded, fixed, and replaced on the fly with no external impact. In an SOA, expected level of service can change after its put into production. For example, we may put a module into service and then increase its expected service level when it is incorporated into a new, mission critical application.
Patrick Logan discusses these points further and concludes: “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.”