Three Roads to the SOA Implementation Framework
No company wants 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 of the tunnel.
The Light at the End of the Tunnel
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. In an enterprise SOA, business users create application functionality by building and managing business processes. Also, the architecture should abstract the underlying technology, so that developer who formerly were concerned with connecting systems and applications can now concern themselves with building Services. 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).
OK, fair enough, but there’s still plenty of dark tunnel ahead before we can get to this vision of the SOA Implementation Framework (SOAIF), which ZapThink introduced in our Service Orientation Market Trends report. The SOAIF envisions a comprehensive framework that provides all the technology that enterprises need to build and run an SOA — process, management, security, modeling, and more. In fact, as enterprises look to implement SOAs, and vendors work to produce solutions that enable such architectures, 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 ZapThink’s 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.
While ESBs can provide the critical infrastructure components that simplify and scale integration approaches, ESBs by themselves don’t provide the required integration 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 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 while 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, while 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 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 EAI and B2Bi 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 exist a wide variety of ways to implement an SOI at runtime, but it’s as yet unclear what approaches are the best for realizing the goals of loosely coupled, coarse-grained, asynchronous SOAs.
The ZapThink Take
ZapThink believes the answer lies in a convergence of the above approaches. 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, run-time 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.