Most commentators recognize an unwillingness to adopt a service oriented architecture (SOA) in one giant leap. In fact it is highly unlikely that any organization is capable of adopting this approach — even if there was a will to do so. That being the case, any initial investment in IT, and SOA specifically, must be closely tied to specific business objectives, and 'belief' in the SOA approach must be built over time, based on the success of these individual projects.

	express delivery
	• print  • comment
	It is baffling to hear an IT professional arguing for 'hard-coded' solutions, within a 'service-oriented' architecture, on the pages of a website called 'loosely coupled'. Ronan Bradley is CEO of integration software vendor PolarLake. The company claims "a proven track record in delivering the benefits of incremental integration with technology that leverages existing IT investments."
	Glossary terms: SOA, ESB, EAI, integration, distributed, lookup tool Sponsored links: your text link here

However, recent claims from some major vendors, and specifically IBM, seem to see this pragmatic approach as offering a loophole: an opportunity to 'rebadge' traditional EAI and point-to-point approaches as somehow contributing to the incremental adoption of the SOA. Putting lipstick on the same old pigs, in other words.

What is "incremental integration"?

My long-held view is that incremental adoption is a two-phase process:

• Define the correct technical architecture upfront, or in other words figure out where we want to get to eventually from an architecture point of view. This initial definition can be very broad (probably no more than general principles), and refined as each project is completed.

• Solve business problems as they emerge by selecting appropriate products and implementing a solution in keeping with the architectural approach agreed in phase one.

This challenges product vendors to provide software that can be used on line of business projects — and deliver business benefits (or ROI if you want to call it that) on each project — as well as scaling to support pervasive SOA implementation. If it works, this is a win-win approach: the architect builds his/her desired architecture one project at a time, while solving those business problems that need to be solved.

All well and good, but there is a danger if the first part of the incremental approach is adopted without the second. To put it another way, adopting a SOA approach (in theory) and then implementing it in ways that will not scale or evolve to fit within the eventual vision simply creates new legacy integration issues. It is an exercise in self-delusion that will undermine one of the fundamental benefits of the incremental approach: the ability to build momentum through success.

SOA without services?

Unfortunately, sometimes the very abstractness of SOA can be used to decouple the first part of the incremental adoption model from the second. If this happens, and one believes that any implementation approach can be used to implement SOA — even to the point where there is no concept of a service — then the term becomes entirely meaningless and hence without benefit.

This approach was perfectly illustrated by IBM's Ali Arsanjani in his recent article on Loosely Coupled, from which I quote the following paragraphs:

"... In order to succeed with this SOI [Service Oriented Integration] approach, and to start from a practical point in terms of IT systems and gradually move incrementally toward the evolution of services within the enterprise, we need to overcome several principal obstacles or challenges ...

The patterns outlined here help resolve those challenges; one pattern per challenge ...

Hard-coded

When: Silo; concentrated functionality (this is not a pattern, but a point in time state)
Why: Low risk; low-changing, high-performance systems.

Point-to-point exposure

When: Distributed; multi-point of access
Why: Expose existing functionality rapidly; unlock value fast; access embedded functionality ...

Enterprise service bus

When: General enterprise integration approach
Why: Mediation; routing; transformation, policies, rules, events; inside the organization or between partners in ecosystem/value-net ..."

I have two strong objections to this approach: Firstly, it is simply not possible to claim to be implementing SOA and then hardcode point-to-point solutions. Secondly, there is absolutely no reason why an ESB cannot be used to solve point-to-point problems or provide high performance solutions. In fact I would go further: a primary criterion for adopting any ESB product must be that it can solve point-to-point problems in an efficient way and deliver high performance.

Frankly, it is baffling to hear an IT professional arguing for "hard-coded" solutions, within a "service-oriented" architecture, on the pages of a website called "loosely coupled".

But perhaps it is understandable when we consider some of IBM's other extravagant claims around the ESB. Only recently Steve Mills told Computer Business Review that "I know we do [have an ESB], in fact I've been delivering ESB functionality for many years".

What is happening here is that IBM is defining the ESB — and above, the SOA — so broadly as to be completely meaningless, in order to claim to offer some form of support for these popular products and architectures.

Crucial differences

On the basis that ESBs must provide many of the capabilities associated with old-style EAI, I agree that IBM has been selling these capabilities for years as part of its product offerings. But there is a difference between EAI and ESB. An ESB must be able to deliver integration capabilities in a manner that is entirely consistent, and yet one that can address the full range of technical problems and thus be used incrementally. That is the whole point, and that is why the ESB enables incremental integration and delivers the benefits associated with that approach.

This is also where all the real differences between EAI and ESB lie; the ESB is standards-based rather than proprietary, distributed instead of hub and spoke, easy to use and adopt rather than complex and costly to implement. So the ESB is not just a new name for the same old functionality. It represents a new approach to integration, and offers new opportunities to organizations that adopt that approach. And IBM, at present, doesn't appear to sell one.

More on this topic