Unexpected Side Effects

or the hidden benefits of an ESB as the core of implementing a Service Oriented Architecture

We usually think of unexpected side effects as something undesirable and sinister. And this view is not inconsistent with reality. Unexpected side effects are much like mutations of DNA — random events. And most of the time a random event is not beneficial. But sometimes it is. Which is why you and I are here — a result of 3 billion years of random events, very few of them beneficial for reproduction of the organisms that we descend from. But yet some were beneficial. Or we wouldn’t even be...

Money saver

Enterprise Service Bus (ESB) main benefits are well documented, as have we summarised below. ESB offers a fast, simple way to integrate systems and applications, helping reduce IT complexity and save money. In brief, ESB’s can:

ESB is a somewhat nebulous term and vendors have been known to classify different software systems as an ESB. Wikipedia provides a list of capabilities that a software system should offer to be classified as an ESB:

support for synchronous and asynchronous transport protocols, service mapping (locating and binding)
addressability, static/deterministic routing, content-based routing, rules-based routing, policy-based routing
adapters, protocol transformation, service mapping
message-processing, message transformation and message enhancement
Process choreography
implementation of complex business processes
Service orchestration
coordination of multiple implementation services exposed as a single, aggregate service
Complex event processing
event-interpretation, correlation, pattern-matching
Quality of service
security (encryption and signing), reliable delivery, transaction management
monitoring, audit, logging, metering, admin console, BAM (BAM is not a management capability in other words the ESB doesn’t react to a specific threshold. It is a business service capability surfaced to end users.)
general agnosticism to operating-systems and programming-languages; for example, it should enable interoperability between Java and .NET applications
Protocol Conversion
comprehensive support for topical communication protocols service standards
Message Exchange Patterns
support for various MEPs (Message Exchange Patterns) (for example: synchronous request/response, asynchronous request/response, send-and-forget, publish/subscribe)
adapters for supporting integration with legacy systems, possibly based on standards such as JCA
a standardized security-model to authorize, authenticate and audit use of the ESB
facilitation of the transformation of data formats and values, including transformation services (often via XSLT or XQuery) between the formats of the sending application and the receiving application
validation against schemas for sending and receiving messages
the ability to apply business rules uniformly
enriching messages from other sources
Split and Merge
the splitting and combining of multiple messages and the handling of exceptions
the provision of a unified abstraction across multiple layers
Routing and Transformation
routing or transforming messages conditionally, based on a non-centralized policy (without the need for a central rules-engine)
Commodity Services
provisioning of commonly used functionality as shared services depending on context

(Source: Wikipedia)

Fine. So this is what an ESB is. Well, at least more or less. Let’s not argue the specific points in the list above. Some may be superfluous, and some might be missing. That’s OK for now.

Competing agendas

But why is it called an ‘Enterprise Service Bus’? Most of the time two of the three words in ‘Enterprise Service Bus’ are emphasized: ‘Service’ and ‘Bus’. Now why is this specific to ‘Enterprises’?

Here goes the unexpected benefit. Anyone who has been in an IT management position knows how easy is to let chaos reign in any IT department. There are various actors in and out of the IT department, and each of them has an agenda, er, make that two agendas each — an official agenda and the real one. Moreover, each of them has a selection of favorite technologies, vendors, protocols, and whatnot. You only need to take a week of vacation to discover on your return that a new system was proposed, support has been garnered, and it is all but impossible to stop the process. And then it turns out that this lovely new system has a user interface of its own, and users must work with one more system. And they’re not happy. And all of sudden it’s your fault!

A blunt tool

An ESB, once deployed and in production, provides an ingenious way to stop this:

So, it provides you with a tool to enforce a policy. It takes some investment to get the tool and the policy implemented, but this is an investment that very quickly pays back.

Now go back to the above list. Anything vaguely resembling “Policy enforcement”? No, not really. But there is a list of technical benefits that are hard to argue with. Consequently, you do not need to go and say to your boss:

You may instead approach from a different angle:


Most of the time an ESB is a relatively easy sell. An ESB is the foundation of SOA, or Service Oriented Architecture. There is a line of books that you can employ to support your advocacy for implementing SOA. Here is a small selection:

Hardcover books from established publishers are not easy to argue against. Few enterprises in fortune-N do not employ an ESB.

There is plenty of support. Users are in favor if this reduces the number of systems that they have to work with, and so is the management which has to support them.

And what about these unexpected side effects? Well, you harvest that as well. As a side effect.