The big enterprise question: ESB vs API

APIs (Application Programming Interfaces) have changed the applications development landscape in this decade. But IT architecture in large organizations are well invested in SOA and middleware products already and such enterprises ask repeatedly one question: What is the difference between an ESB (Enterprise Service Bus) and an API ? or why shouldn’t we simply use ESB to create APIs ?

We may have to go back to the roots of what SOA and API represent conceptually.

SOA (Service Oriented Architecture) creates common service models on top of legacy systems, vendor dependencies, incompatible interfaces. APIs have transformed IT architecture from stacked layers to a network of interconnected domain models.

APIs focus on application building, whereas SOA focuses on creating resources to plug in. ESBs and Message Brokers play a integration/data exchange role in SOA.

While there are many technical answers, I wanted to give a more expressive idea. Comparing ESBs to APIsis similar to comparing Tunnels to Cities.

Consider an urban planning architecture. It’s aim is to create assets for social and economic benefits (of population). It does this with planned infrastructure and environment using policies and standards. Urban development involves creation of landscapes for usable living: home/office spaces, transport structures such as roads and bridges, water supply and sewers.

It has a utilitarian aspect.

APIs can have a similar utilitarian interpretation. From traditional monolithic application structures, both web and desktop, API’s transform IT into a connected multi facet architecture with every API having a well defined aspect. APIs provide maximum utility to different parts of an application by applying data models and modular design principles. They are a deviation from legacy application development.

Going back to our urban planning correlation, though urban planning makes city design easier, natural geography might limit the size of the planning, like mountains, water bodies, uneven landscapes. To overcome any limitation, architects resort to highly technical structures with heavy budgets, like Tunnels, suspension bridges, etc.

ESBs and message brokers have the same characteristics of complicated structures like tunnels. When certain parts of enterprise architecture do not communicate well or increase in size, ESB’s can simplify the passage of message between them. One of the systems may be a slow processor, so queueing of messages may be required. One of them may need a binary data format, so transformation of messages will be required. Simplified integration structures and patterns are the target achievements of ESBs and Message brokers.

SOA provides a foundation of service models by hiding the layer underneath it — the complexity of vendor dependent systems (Application Servers, Mainframes, ERP, ETL/MDM, Content managers ...) ESBs on the other hand are built into the “middleware” stack to overcome integration problems in traditional SOA.

Though ESBs have a utilitarian aspect, their use is aimed at reducing the limits of IT Architecture.

The implementation and technology of ESBs can be technically impressive, but there are reasons for why they cannot consume the whole IT infrastructure. When large middleware containers run application logic, new application use-cases become tough to be introduced in that ecosystem. Every new requirement will require additional infrastructural spending. The more ESBs become logically involved in a business use-case, the less flexible IT assets will become.

APIs on the other hand, encourage creation of logical parts which are reusable. Every new use-case introduced can be easily decomposed into smaller artifacts. API catalogs give an understandable documentation. Business Analysts, Consumers, Third party app developers all work hand in hand. API economy and monetization takes the benefits of IT infrastructure beyond an organization’s borders.

APIs simplify application development and apply organizational policies like security, access roles, enterprise data standards, into different parts of an application. APIs have changed the layout of software architecture from being heavily layered into a highly interactive graph.

Tunnels are fascinating. They need technical expertise. But Tunnels are not the same as Cities. They both have their own functional areas.