Service-Oriented Architecture: The End of Integration?
Three roads can take you from the brittle integration of the past to hands-free integration of the future
by Jason Bloomberg and Ron Schmelzer

Posted June 25, 2004

No company wants to deal with integration. The only reason anybody spends money on integration at all is because software as a rule doesn't integrate by itself. But no executive thinks that spending money on integration addresses a strategic need of the business. Instead, money spent on integration goes for fixing something that really shouldn't have been broken in the first place. The sad fact of the matter is that in the forty-plus year history of distributed computing, integration has constantly been a money-suck for every company with two or more computers that need to talk with each other. It's been a long, dark tunnel, but now—finally!—we can see the light at the end.

Fundamentally, software must integrate without significant human intervention. In other words, the distributed computing architecture itself must provide the necessary infrastructure to resolve integration issues while putting application development into the hands of the IT user. A service-oriented architecture (SOA) abstracts the underlying technology, so that developers who were formerly concerned with connecting systems and applications can now concern themselves with building services for business users to access. As a result, the entire IT mindset must then shift from connecting A to B (the integration mindset) to building business services that abstract IT functionality (the service orientation mindset).

Service orientation is an approach to distributed computing where software functionality is available as discoverable services on the network. SOA is the practice, or discipline, of organizing systems, applications, and their environment to provide service orientation. Service orientation, however, is more of an approach to distributed computing than a market category per se. As companies come to understand the value proposition for service orientation and SOAs, they may find they need a range of software, hardware, and consulting services to put together an IT infrastructure based on an SOA. The trend in the IT marketplace is toward a consolidation of most service orientation functionality into a single market category that can be delivered as individual products, product suites, or service offerings that contain broad functionality, including features that are currently associated with the security, management, process, integration, and tools segments. This might be called an SOA implementation framework, or SOAIF.

OK, fair enough, but there's still plenty of integration dark tunnel ahead before we can get to this vision of the SOAIF. The reason integration is the key problem is because of the fundamental nature of distributed computing. During the history of distributed computing, getting computers to talk to one another has essentially been a difficult problem. As integration became more of a business imperative, solving various integration problems gradually consumed an increasing portion of the IT budget. If at some point the integration problem is addressed architecturally, rather than through distinct products, then resources will no longer have to go toward integration.

The resulting savings is one of the promised benefits of moving toward an SOA. Integration itself, of course, won't go away; in fact, just the contrary—in the service-oriented world, application integration is automatic and ubiquitous. In fact, as enterprises look to implement SOAs, three separate approaches to integrating disparate, heterogeneous information and systems in the enterprise are in the process of converging to provide an optimal implementation of an SOA—one that meets the requirements for loosely coupled, coarse grained, asynchronous services. The following three approaches, therefore, are essentially transitional approaches leading to the SOAIF that underlies the vision of service orientation.

Approach #1: The Enterprise Service Bus
One approach that contributes to an optimal SOA implementation is the use of an enterprise service bus (ESB) to provide an infrastructural element to distributed services on the network. The ESB approach to integration considers systems as discrete, distributed services that connect to each other via an asynchronous, message-oriented communications infrastructure. The message-oriented infrastructure allows loosely coupled, document-oriented exchanges between independent systems.

Although ESBs can provide the critical infrastructure components that simplify and scale integration approaches, ESBs by themselves don't provide the required coarse-grained service definitions to meet high-level business requirements, and neither do they necessarily provide guarantees of loose coupling and coarse granularity to meet evolving service-oriented needs. Basically, implementing ESBs to meet SOA requirements require the addition of extra functionality to compose fine-grained atomic services into coarse-grained business services and provide policy-driven, managed, and secure service interactions.

Approach #2: Business Process Management
Companies have long sought to solve these higher-level business process issues by implementing business process management (BPM) approaches that consider systems and IT assets as activities or tasks that participate in well-coordinated and centrally orchestrated business processes. Traditionally, the challenge of BPM is that although it is possible to construct processes that achieve integration goals, enterprises typically use BPM tools only at design time, modeling processes as they used to be or processes as they should be, but rarely processes as they actually are in the IT environment.

So, although BPM solutions can craft orchestrated processes that are composed of fine-grained services, they don't contain the runtime environment necessary for loosely coupled, asynchronous service interactions. At the very least, a BPM solution must be used in conjunction with a loosely-coupled integration approach to make the business processes runtime activities that coordinate integration. Thus, by itself, BPM solutions aren't sufficient to meet SOA requirements.

Approach #3: Service-Oriented Integration
The service-oriented integration (SOI) approach uses the architectural guiding principles of service orientation to construct an ecosystem of services that business users can dynamically combine and compose into higher-level processes that meet continuously evolving and changing business requirements. SOI approaches transcend brittle, tightly coupled enterprise application integration (EAI) and B2B integration approaches by mandating a separation of the consumer of each service from the producer of that service, thus enforcing the critical aspect of loose coupling that is required to allow an integration scenario to evolve automatically to meet business requirements.

Yet, even SOI by itself provides no guidance on how to build the right services to meet current business requirements, nor does it provide a means to execute services in the most effective, scalable manner to guarantee long-running interactions. Furthermore, there exists a wide variety of ways to implement an SOI at run time, but it's as yet unclear which approaches are the best for realizing the goals of loosely coupled, coarse-grained, asynchronous SOAs.

Next Steps
The best approach to achieving the long-term benefits of SOAs lies in a convergence of these techniques. The message-oriented, loosely coupled approach of ESBs provide an optimal base on top of which to run the loosely coupled, coarse grained services implemented in an SOI. BPM solutions provide the process-driven guidance necessary to ensure that they compose fine-grained services into real, runtime business processes. Through the combination of these approaches, companies can move toward the vision of software that integrates automatically.

Nevertheless, it is important to understand that the hands-free integration vision of service orientation is still many years off—and systems and applications must talk to each other today. Fortunately, there are roads enterprises can take that will lead them from the brittle, expensive integration of the recent past toward this grand vision. ESBs, BPM solutions, and SOI approaches are all roads, that when taken together, lead to true service orientation.

About the Author
Jason Bloomberg and Ron Schmelzer are senior analysts with ZapThink LLC.