Sure we do! But… Wait a minute. What is ESB? Is it yet another 10-year-old “fancy” technology on its way to Valhalla? Before answering these questions, let us first understand what does this term actually mean.
Wiki says that
An enterprise service bus (ESB) is a software architecture model used for designing and implementing communication between mutually interacting software applications in a service-oriented architecture (SOA)
So ESB is not a technology; rather, it is an architecture model. And yes, buying and implementing ESB products like Oracle Fusion Middleware, IBM Integration Bus or WebMethods Integration Platform will not automatically convert your enterprise to ESB-enabled. Many enterprises face problems that are related to this fact, cause usually CIO thinks that everything will look exactly as in the Oracle booklet, if you just pay for licenses. Unfortunately, this is a false statement, and these products are mere enablers for ESB implementation.
It is usually expected to see beautiful pictures where all the complexity is hidden behind the ESB layer. It is assumed that everything inside ESB is well documented, monitored and governed:
Unfortunately, it is not always true, and the final picture is likely to become more complex than anticipated:
As a result an enterprise has an ESB product, but doesn’t have the right architecture in place. What can we do about it? I think that we should always remember the core values that ESB should be adhering to, the most important of those being:
- Governance and visibility – at any time we should know exactly which system can invoke which service, and in what format / version.
- Protocol abstraction – application should not care what protocol is being used, as this should be handled by the ESB layer automagically.
- Format abstraction – application should not care what data format is being used (XML, JSON, CSV or any other), since all the transformations should be executed by the ESB layer, transparently to an application.
- Security policies – common security policies should be audited and in place.
- Monitoring – should always be on and be tightly integrated with governance.
- Routing – application should not care where and how its request will be routed, as well as whether the load balancing will be on or off.
- Highly distributed integration environment – it should not be a problem to scale the whole platform or a singled out integration service.
As a result, all these values should allow achieving these IT goals:
- Rapid development – full picture will let us develop and change rapidly, despite of system complexity.
- Maintenance cost cut – it should be cheaper and faster to find where the problem is, when an ESB architecture is in place.
- Redundancy reduction – it should be a really fast process to understand, whether a new service should be created, or an old one reused instead.
It is really not obvious how to achieve the above goals. If you see that your organization is missing something, you have to act now! Micro-services, cloud integration and internet of things are coming, and it will be even more challenging to solve these issues later on, as your integration infrastructure matures and evolves. Don’t hesitate to get in touch with us, if you need help!
 |
About the author: Antons Matrosovs is a head of application integration capability in Idea Port Riga. He has 9 years of hands-on experience working with various integration platforms and participating in a wide variety of projects in different roles, thus becoming an expert in enterprise and integration architecture, business analysis, as well as project and team management. Antons is particularly interested in SOA Governance lately – he has recently taken part in several big projects, where it was defined as one of the highest priorities. |
