As enterprises build SOAs, the going is pretty slow, thanks mainly to a vastly increasing number of dependencies. Here’s what you can learn from what’s happening on the ground
Ask anyone in charge of constructing an SOA (service-oriented architecture), and they’ll tell you that the hardest part isn’t the technology; it’s redrawing the business processes that provide the basis for the architecture — and the often contentious reshuffling of roles and responsibilities that ensues.
Many SOA practitioners say that, so it must be true. But the technology part isn’t necessarily easy, either. After all the planning and strategizing is complete, services and their messaging infrastructure must be provisioned and managed, alongside whatever platforms, applications, and systems are already in place.
The ultimate objective of SOA is a supremely agile infrastructure, where IT develops composite applications atop of a layer of abstraction that spans multiple platforms and domains across the enterprise. But nobody can “boil the ocean” and achieve that goal all at once. Practical SOA initiatives begin with a related set of business processes that would clearly benefit from greater flexibility — where market conditions are in constant flux, for example, or new services must be deployed on the fly for competitive reasons. At some point that top-down approach meets the bottom-up reality of existing software assets and infrastructure.
When that rubber meets the road, technologists must make key decisions about the platforms on which to build services, as well as how those services will be exposed, managed, and mediated. Some companies may opt for an ESB (enterprise service bus) to connect services, whereas others may focus on standards-based services designed for maximum reuse. Examining the decisions companies make in the real world provides valuable lessons for those who actually need to build — rather than just talk up the benefits of — an SOA.