Integration systems: why the ESB is an outdated approach

5 minutes read
04 June 2021

For many years, enterprise service bus (ESB) has represented the choice – among integration systems – to allow business applications to communicate with each other and thus functionally connect the most important business processes. A model of success until the new cloud applications appeared and, with them, the need to use different integration systems, also based in the cloud.
This is the case of Data Fabric, iPaaS (integration Platform as‑a‑Service), and what Gartner analysts call the Digital Integration Hub (DIH).

Let’s see how the different integration systems work and why the new DIH paradigm represents an important generational leap compared to the already existing integration solutions.


Enterprise Service Bus (ESB) and its role among application integration systems

The Enterprise Service Bus (ESB) is an architecture born in the early 2000s to connect multiple applications together through the adoption of a “bus” type architecture. The ESB is a widespread integration system suitable for equipping service‑oriented architecture (SOA) by decoupling individual applications. In this way, the applications can communicate with each other without depending on other systems connected to the bus, as point‑to‑point integrations work, which are more complex to update and to monitor in operation.

An ESB system uses REST APIs – that are application interfaces compliant with the REST architectural standard (the representational state transfer designed to support distributed systems) – business logics and multiple protocol connectors for message exchanges in open formats such as XML, but also through files, binary data, and whatever else it takes to communicate with proprietary and legacy applications.

ESB is characterized by a centralized approach, suitable for monolithic applications, which does not shine for scalability and robustness. Performance can only be improved by scaling the entire integration system, risking a single point of failure. Code and business logic depend on the system supplier, and this means that the ESB approach involves a high risk of lock‑in with the supplier and can be an obstacle to future evolutions.


iPaaS vs ESB: cloud integration in the platform as‑a‑service logic

Gartner defines iPaaS as “a suite of cloud services enabling development, execution and governance of integration flows connecting any combination of on premises and cloud‑based processes, services, applications and data within individual or across multiple organizations”. 
Born from the integration tools designed for ERP and CRM, iPaaS have evolved in the form of complete integration platforms, supporting the cloud development of medium‑large companies for a decade, as an alternative to ESB.

As cloud‑based systems,, iPaas allow greater scalability than ESBs, and they are effective in supporting the integration of large data flows with distributed systems or even external to the organization.
iPaas limitations involve the use of proprietary technologies, the centralized approach and significant licensing costs; moreover, they don’t allow to reduce the workload generated by calls directed to the underlying systems.

Today, as markets push the business to evolve towards omnichannel logics, to create value for the user experience and for the management, collection and analysis of data, iPaas don’t seem the right solution, as they don’t solve the need for data decoupling.


ESB vs microservices: the Digital Integration Hub innovation

The concept of Digital Integration Hub (DIH) is the most recent among integration systems. In 2019, Gartner described it in its report as “an emerging architecture destined to become fundamental”, placing it in the spotlight. This paradigm is today widely adopted by large companies (accessible content for Gartner customers only).
The DIH serves the purpose of achieving a complete decoupling of systems from contact points, by best supporting cloud‑native technologies, containerized microservices, Rest and GraphQL APIs, and event architectures.
In terms of data, the DIH is suitable for supporting 24/7 fast data flows in real‑time, and for the creation of Single Views, unique views on the most significant data specifically aggregated.

The DIH is characterized by an approach that combines effectively with modular solutions, such as containerized services that scale independently, guaranteeing performance and operational reliability.
Among the integration systems, the DIH offers an open approach that avoids lock‑in allowing you to deploy the code on different platforms at any time and to realize the mainframe offloading, reducing loads and significantly cutting costs.

Why the Digital Integration Hub is the best choice to solve today’s and tomorrow’s problems

In a market situation that forces companies to be faster in their processes and effective on every channel of contact and sales with customers, integration systems become the key to guaranteeing greater flexibility and a better customer experience.
Among the most recently defined integration systems, the DIH combines the prerogatives of lightness and scalability that derive from the use of the cloud together with those of support for distributed and real‑time data flows that are necessary for new applications. The data aggregation capabilities allow up‑to‑date unitary views on business trends and customer behaviors in a multichannel logic. The openness of the architecture protects from the lock‑in towards suppliers and is at the same time a promise for future developments.

New call-to-action
Back to start ↑
Enterprise Service Bus (ESB) and its role among application integration systems
iPaaS vs ESB: cloud integration in the platform as‑a‑service logic
ESB vs microservices: the Digital Integration Hub innovation
Why the Digital Integration Hub is the best choice to solve today’s and tomorrow’s problems