Applications and end users of applications require specific information, usually provided by apps such as for banking or shopping. The origin of the information shown in these apps is an underlying source system or a set of systems that compares and merges information. Many financial enterprises focus on providing clients with a modern app, which are, however, often cursed with a legacy system from the 1980s or even older as their information source. Consultant Rudy van Haandel explains the role that integration solutions such as an Enterprise Service Bus (ESB) and API Management can play in these situations.
ESBs are made up of integration software that deals with communication between various systems that are not directly connected. The ESB manages the delivery of messages; known as orchestration, thus ensuring:
that applications receive the correct messages from each other;
that messages are transformed so the receiving system can read the message;
that message streams are secure and nobody monitors them;
that caching is dealt with so applications are not suddenly overloaded with messages during peak periods;
monitoring, to allow for measuring and gaining insight into the number of messages.
The term Enterprise Service Bus has been around for quite a while, and in recent years both the term and the concept have undergone a transformation. An ESB used to function as a ‘holy grail’ and was set up as an integration layer to automatically deal with any integration issues. Simply shouting ‘ESB!’ would make any issue magically disappear, not in the least because integrations were in-company at the time.
Collaboration has since strongly increased, and integrations primarily run between or across various companies. Other integrations involve a large number of companies and applications that are not known in advance, for example platform strategies. In this case, ESB often turns out not to be ideal because of tight coupling, as the loose coupling of APIs is more suitable.
An end has come to the time in which large on-premise ESB products, such as Oracle ESB, Tibco ESB and IBM WebSphere ESB, functioned as stand-alone overall solutions. In addition, they have found counterparts in the emergence of a blend of cloud and on-premise solutions, such as Azure ESB and a set of features offered by Azure Logic Apps, or AWS Stepfunctions and AWS Event Bridge that provide similar ESB functionalities.
Gone are the days when a website was enough for a proper, digital presence. Our experts happily assist in bringing about a digital ecosystem - optimised and on-brand - fit to serve your business goals.
If you are going to link many applications that you can manage well yourself, an ESB can be an excellent, robust option. When applications need to be linked that are not all within your span of control, (public) APIs and associated API managers (for example Red Hat 3Scale or Apigee) are often a better fit.
Both solutions – APIs and an ESB – have situation-specific advantages. Some of the ESB features, such as caching and message transformation, are also available in the API manager, or smaller components in the form of microservices are set up to design and unlock specific functionalities in the integration landscape. This allows development teams to switch more rapidly and prevents them from having to deal with all the components in an architecture.
In short, the Enterprise Service Bus is still around, with advantages and possibilities, but be sure to properly map out your company’s integration requirements before making a choice – whether with a specialist or not. The main objective, after all, is to set up an application landscape to support the digital transformation of your company, today as well as in the future.
With over 25 years of experience in sales, Rudy still gets a kick out of getting to know new clients and solving challenges through the right digital solutions. The man to talk to for all things financial services, integrations and identity & access management – he’s often found laying the groundwork of a promising MVP.