The Enterprise Service Bus (ESB): is that still around?

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.

Bus and blocks

ESB properties

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.

Is ESB still trending?

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.

From stand-alone to the cloud

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.

ESB depends on type of integration issue

Today, the integration issue type determines whether an ESB or another integration solution is best deployed. The differences are as follows:

  • The ESB often proves to be an excellent and robust option if many applications within one company are linked.
  • When integrating between and across multiple companies, APIs and associated API managers (Red Hat 3Scale and Apigee, for example) provide many additional benefits.

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.

rudy.png
More information about integration?

If you would like to receive advice about an integration issue or have a specific question about API Management or an ESB, Rudy is happy to help!

Contact