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…
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:
- Control and monitor the routing of messages between systems.
- Help with deployment of a new version of a system.
- Translate messages between different formats and coding tables.
- Provide services, such as message and event queuing.
- Provide a security framework.
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:
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.
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:
- Hold on guys… we’ve decided that everyone talks to the ESB and user interface is via the CRM system, right? We’re not changing this decision… or are we?
- Right, that’s what I thought. I’m glad we all agree.
- So, we’ll have to talk to that new vendor and ask them nicely to comply with our policy if they want our business.
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:
- We really need to implement an ESB so that I have some tool to curb top management’s (and yes, this includes you, boss) whimsical desires and pet vendors.
You may instead approach from a different angle:
- We really need to implement an ESB. An ESB provides us with facilities that allow Messaging, Mediation, Routing, Protocol conversion, Routing and Transformation, Commodity Services, Message exchange patterns, Quality of service, Complex event processing, and Adapters for many legacy systems.
- And, boss, remember that new system that you do not like on users’ desktop? Guess what, we can connect it to the CRM, so the CRM is what users work with.
- No, it’s not going to be expensive or lengthy; we can do it quickly. Yes, I checked with the CRM vendor, and they would be happy to help.
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:
- Service-Oriented Architecture (SOA) Compass: Business Value, Planning, and Enterprise Roadmap
- Service-Oriented Architecture (SOA): Concepts, Technology, and Design
- And, naturally, did you ever doubt it:
Service Oriented Architecture (SOA) For Dummies
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.