Be careful using EAI Platforms, they can be too much of a good thing

It is not a golden hammer for IT integration.

An Enterprise Application Integration (EAI) product makes up for deficiencies in Services and the Clients. A mature Service Oriented Architecture minimises the need for it.

Traditionally called an Enterprise Service Bus (ESB), its most important features are listed below. The S or C after each feature indicates if it is for the Service or for the Client.

1. Queuing (provides capacitance for accumulating a batch of client requests for sequential dispatch to protect the service from spike loads) — S
2. Publish-Subscribe (decouples the service from multiple consumers by avoiding the need for client-specific knowledge and frequent changes) — S
3. Protocol & Object Transformation (aka Brokering; allows communication between clients and services using differing protocols and data transport formats) — C or S
4. Orchestration (perform a multi-step operation; hold state and validate with and/or update multiple systems) — C or S
5. Retrying (Try again a set number of times at a set interval in case of service call failure) — C
6. Aggregation (Join information or functionality from multiple services and supply the result to the client) — C
7. Routeing (Choose the system to query or update based on reference data and rules) — C
8. Sync-Async Conversion (Hold state for an async response service and respond to a sync call; hold state for an async client and do a callback from a sync service) — C

Now, if we build features 1 and 2 into the Services, 3 and 4 in both Services and Clients and 5–8 into the Clients, we will slash the need for a separate Integration product.

In any integration landscape, the total number of connecting lines and hops is a good sign of the long-term integration cost. It is simplistic to think that an ESB platform is an elegant and efficient answer for the integration of many clients and services in a large IT system. It may look good in a diagram to see all systems connected to an ESB, like spokes to a hub. But scrutinise and it is no simpler than directly connecting a set of mature services to mature clients. The latter may look like a cobweb or tracery, but the total number of lines and hops will actually be less. This is a way to see the big picture.

Over-reliance on an EAI platform increases complexity, network load, latency, Infrastructure (CPU, RAM, Disk) costs, build cost, licence costs, change costs and support costs. The time for all life cycle phases also increases. This includes needs gathering, testing, deployment, change management and problem-solving.

Avoid the overuse of EAI products through a well-developed Service Oriented Architecture. One that is by definition based on standards for protocols and data exchange formats. One that builds services and clients from the beginning based on the core Principles of Architecture — Decoupling, Cohesion and Reuse.

This is not to say EAI platforms do not have a place in a mature IT landscape. They do, especially for aggregation of data and functions from multiple sources and orchestration of multi-step operations over existing systems.

In most cases, we will already have an ESB product. It tempts us to use it whenever we need to integrate two systems. Instead, use the litmus test of a needs checklist and make sure it is the best choice.

An EAI/ESB Platform is not a Golden Hammer for Enterprise Integration. Rather, it can become a blanket covering bad SOA if we are not alert.

---

Connect with me: