|
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.
Back to top
|