Perfect Integration 9 - history with hindsight

In the previous post, the history of Integration passed: point-to-point, EAI and ESB. For those who read and grasped post 1 through 7, it'll be clear why I favour which one - but let me explain it in more detail

What are the differences between the different historical approaches?

The crucial difference is that EAI describes a hub and spoke architecture, where proprietary messages to and from applications are translated by a central integration broker. Yes, that is the European Parliament post, among others.

As described, applications can plug in and out of the landscape this way, and the necessary transformation of information is taken care of by the central hub

In an ESB, there is no hub: the hub has become a bus. Transformation of information is done by the applications themselves, who thus custom-built their (small) integration engine which does the job. If you want to plug into the Matrix there, you have to follow all the courses - and that takes a lot of time and money, unlike Neo learned combat

There are advantages and disadvantages to EAI as well as ESB

Greatest advantage of EAI is its cost effectiveness, and the fact that it can support just about anything.
Greatest advantage of ESB is the fact that it doesn’t support just about anything, but needs and enforces a highly standardised environment

The biggest disadvantage of EAI is the fact that scalability might become an issue because everything goes through the central hub, but that worry was years ago. The biggest disadvantage of an ESB is the fact that there are either numerous and various integration brokers in the landscape, each tightly coupled to the applications themselves, with a highly specialized knowledge required, and a lot of licensing costs involved, or add-ons to existing applications and systems that might not be part of the default architecture in mind.
In either case, they're mostly uncontrolled, bespoke, and hard and costly to maintain. And basically, in this scenario, the ESB does nothing else than route messages - now how exciting is that?

From an IT enterprise point of view, there is not much of a difference between properly conducted EAI and ESB: applications are decoupled and accessible via services (or standardized interfaces) and as such appear to be plug-and-playable to the business. From a business PoV, however, cost plays a role, time-to-market, and flexibility: and that's where pure ESB's lose hard, compared to EAI


It is somehow even strange that EAI has been “followed up” by ESB, as hardware costs have dramatically decreased over the last few dozen years.
On the other hand, integration has become so obvious that most packages now offer a small integration suite with the system itself. However, these are still as monolithic as the majority of those systems themselves, and never capable of handling enterprise-wide integration if there are more packages involved than just their own (cf. SAP XI / PI. Getting better every year, they pale in comparison to integration brokers 15 years ago). They are small message brokers, capable of doing some lightweight transformation at best

In order to make ESB viable, integration suites coming along with entire systems should be fully able to handle Enterprise Integration, and they should be included in the system, not sold separately as an option. If it’s not part of the default package, where is the benefit? In the 21st century, every single application should be able to integrate with other applications by "disclosing their functionality" in the form of a message.
Message transformation will always be necessary, as there can be no such thing as a worldwide agreement on business documents, as the experience of the past 30 years has clearly shown. No matter which standard exists, parties will always make their own subset, or grow away from it; compare this to the average dictionary that describes a full language, and of which no more than very small subsets are used in day-to-day communication

So, currently, put your money on the hub-and-spoke architecture of EAI, due to the fact that it is still very -very- costly to realise a true Enterprise Service Bus within most companies the pure ESB way. It is far easier, faster and cheaper to use the EAI model and a Canonical in order to achieve a uniform language across your diverse IT-landscape

In post no. 10, I'll address the magical mechanism that enables all of this: one uniform business language across an ocean of diverse IT applications, messages being translated from any language into an intermediate one, and everything being seamlessly transported from A through B and back to finally Z; the most important part of integration, usually if not always forgotten:

the envelope