Difference API and ESB

So, where there is a lot of discussion is whether API platforms do replace ESB (Enterprise Service Bus) and what are the specific purposes between the two. The truth is that both integration platforms have dissimilar objectives and features and grew out at different moments of time. 

As mentioned as ESB provides integration between back-end systems (system of record) in a company. Traffic is predictable, security is within company premises and systems technologies (mainframe, Java, .Net etc) and data formats may be very different. Additionally, most of these interfaces may involve transactions that needs roll-back and error handling mechanism in place in case of failure. We use it mainly for horizontal integrations as the interfaces are mainly between back-end systems. 

API Management is focused on vertical integration between backend systems (systems of record) and front-end channels and third parties, the so-called systems of engagement. The features therefor are different as it needs to handle large peaks of traffic, traffic control, security and agility amongst others. I believe the following diagram explains the difference between vertical and horizontal integration: 

We summarize the differences and main characteristics between Enterprise Service Bus (ESB) and API Gateway in the following table:

Note that both API and ESB vendors are trying to bridge their gaps and are incorporating or acquiring the "other side" of this spectrum within their own product. Nowadays, most vendors do offer both products either as one integrated product or two complementing parts.

You can read more about different integration architectures in the post "Evolution of Integration Architectures". 

Use only API Gateway or need for ESB?

Most companies adopted an ESB within their company, but end up not using all its characteristics, and one question I am often asked is whether companies still need an ESB in this case or move towards an API platform to manage integrations within an enterprise.  

At the end, taking apart the technical features, one can build ESB and APIs integrations very similar from a business perspective and the truth is that many new startup companies do use instead of an ESB an internal API platform to integrate between their systems and another "external" API gateway to expose their APIs to external systems. 

So, should a company with traditional  architecture move towards an integration architecture 100% based on APIs? The answer to that question depends on three factors:

1. Current Integration Complexity Needs 
2. Legacy Debt & Number of Integrations
3. Company's IT Strategy

1. Current Integration Complexity Needs

The first  factor is the complexity and needs of current integration landscape. Are there many  integrations between its back-ends? Are these integrations complex? Are there many transformations, translation and/or orchestrations built within these integrations? Are integrations built with restart or rollback capabilities? 

If so, API-fying is not the way to go forward as the ESB here serves well its purpose. You want to avoid building an ESB on an API platform which is far more risky than maintaining your existing ESB. 

2. Legacy Debt & Number of Integrations

Most companies do have a legacy debt, where older systems exist with many integrations between them. Most companies moved towards an Enterprise Service Bus to centralize their integrations and in their search for efficiency and robustness while able to interconnect any protocol and data format between their applications. 

In case there are already many back-end systems and significantly large number of integrations, it may be a costly exercise to move towards APIs and API-fying your company, while benefits are very low.

3. Company's IT Strategy

But more importantly in this decision to API-fy your company, is to think of the future. Do you want your company to be become the next Amazon platform, where customers and other external parties can actually access directly your inventory, payment and other back-end system functionalities?  Or do you want to only provide digital channels to your consumers where clients can browse and buy products on your web portal and mobile applications? 

If your strategy is to open up your company and provide native company's services to the outside world, you have a reason to open up your legacy systems and look towards a world of APIs in all your systems. The consequence is that you have to replace your existing integrations with APIs and avoid duplicates to avoid costly maintenance of both an API and an ESB interface. 

As mentioned, it will cost to convert existing integrations into useable APIs and reconnect them again, but once being converted to an API, you can leverage them to third parties to connect with your systems natively. You need to think of data and security implications as well, but again, that is where the API gateway helps. 

So if the benefits (little legacy debt and ability to become a 100% digital company) weigh out the investment (cost of replacing existing integrations with APIs), you are ready to replace your ESB with an internal API gateway and API-fy your traditional architecture into a 100% API-fied landscape. But in reality, in most cases, as companies have large number of integrations, already invested in an ESB in their landscape, the cost is too high to justify the change....