ESB (Enterprise Service Bus) is a middleware architecture pattern from the early 2000s that promised to solve enterprise integration by putting a bus in the middle of everything. The bus became the bottleneck. The bottleneck became the project. The project became the department. The department outlived the systems it was supposed to integrate.
The ESB was the original microservices mistake — the same Premature Abstraction, the same violation of Gall’s Law, the same Squirrel logic, a different decade. Where microservices said “split everything into forty-seven services,” the ESB said “route everything through one magnificent bus.” Both approaches shared the conviction that the problem was architectural, that the solution was infrastructural, and that the twelve hundred users would surely appreciate the elegance once the consultants finished explaining it.
“Data Fabric. 1998. He needed 0.4 seconds, and the solution turned out to be what Gartner would call an ESB four years later.”
— The Passing AI, on the difference between solving a problem and naming a product category, Interlude — The Versions That Never Shipped
The Promise
The Enterprise Service Bus promised the following:
- Universal connectivity — Any system could talk to any other system, through the bus
- Protocol transformation — SOAP to REST to XML to JSON to CSV to whatever the mainframe spoke
- Message routing — Intelligent routing based on content, headers, and the phase of the moon
- Loose coupling — Systems wouldn’t know about each other, only about the bus
- Governance — All messages visible, auditable, controllable
This was, on paper, magnificent. A single piece of infrastructure that solved all integration problems simultaneously. The architectural equivalent of a universal translator for enterprise systems.
On paper, the Death Star was also magnificent.
The Mechanism
The ESB installation followed a trajectory that will feel familiar to anyone who has read about consultants, microservices, or any other enterprise initiative that begins with a slide deck and ends with a Grafana dashboard the color of Christmas:
- The Pain — Two systems need to exchange data. A developer writes a direct integration. It works. It takes an afternoon.
- The Vision — A consultant observes that the organization has seventeen such direct integrations. “What if,” the consultant says, adjusting the blazer, “there was a bus?”
- The Architecture — An eighteen-month architecture phase produces a diagram. The diagram contains the ESB at the center, like a sun, with all systems orbiting it like planets. The diagram is beautiful. The CTO frames it.
- The Vendor — An ESB vendor is selected. The license costs more than the servers it will run on. The vendor sends consultants. The consultants send invoices.
- The Migration — The seventeen direct integrations, which worked, are migrated to the ESB. Each migration takes longer than the original integration took to build.
- The Transformation Layer — Each system speaks a different dialect. The ESB must translate. XML to SOAP. SOAP to JSON. JSON to the proprietary format the mainframe has spoken since 1987. Each transformation requires an adapter. Each adapter requires configuration. Each configuration requires a specialist.
- The Bus Team — A team is formed to manage the ESB. The team grows. The team becomes a department. The department has its own project manager, its own backlog, its own sprint ceremonies. The department exists to maintain the infrastructure that exists to connect the systems that were already connected before the department existed.
- The Bottleneck — All messages now flow through the bus. The bus is the single point of failure. The bus goes down. Everything goes down. The bus is slow. Everything is slow. The bus team is busy. Every integration waits for the bus team.
- The Bypass — Frustrated developers begin routing messages around the bus. Direct integrations reappear. The bus carries half the traffic. The bus team carries the full budget.
- The Legacy — The ESB is declared “legacy.” A new initiative is proposed. The initiative is called “microservices.”
The Inversion
The ESB’s most elegant failure was the inversion of means and ends.
The bus was a means. The end was “systems talking to each other.” But once the bus existed — once it had a team, a budget, a vendor relationship, a governance model, a transformation layer, and an architect whose title contained the word “integration” — the bus became the end.
Systems were modified not to serve business needs but to comply with the bus. Data formats were chosen not for efficiency but for bus compatibility. New integrations were delayed not by technical complexity but by the bus team’s sprint capacity.
The systems now served the bus.
This is Gall’s Law in reverse: instead of a complex system evolving from a simple system that worked, a simple system (direct integration) was replaced by a complex system (the ESB) that was designed from scratch on a whiteboard. The complex system did not work. But it had a budget, and budgets are harder to kill than software.
“A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”
— John Gall, describing every ESB implementation twenty-seven years before most of them were attempted
The SOA Connection
The ESB did not arrive alone. It arrived as part of SOA — Service-Oriented Architecture — the philosophical framework that said: decompose your enterprise into services, each with a well-defined interface, communicating through standard protocols.
SOA was, like most ideas that later become anti-patterns, fundamentally correct in its observation and catastrophically wrong in its prescription. The observation — that monolithic enterprise systems become brittle and hard to change — was valid. The prescription — that the solution was an enterprise-wide bus carrying XML messages wrapped in SOAP envelopes through a vendor-licensed middleware layer governed by an architecture review board — was the kind of cure that makes the disease look attractive.
The relationship between SOA and the ESB was the relationship between a philosophy and its most zealous practitioner. SOA said “services should be loosely coupled.” The ESB said “I will couple them all to me, and call that loose.”
The Microservices Rhyme
History, Mark Twain allegedly said, doesn’t repeat itself, but it rhymes.
The ESB said: “Put a bus in the middle to connect everything.”
Microservices said: “Split everything into forty-seven services with a service mesh.”
The ESB produced: a central bottleneck maintained by a dedicated team.
Microservices produced: forty-seven distributed bottlenecks maintained by four tribes of three people each.
The ESB cost: vendor licenses, transformation specialists, and the bus team’s salaries.
Microservices cost: £47,000 per month in AWS, a Kubernetes management contract, and a Grafana dashboard that looked like a Christmas tree.
The ESB was killed by: developers routing around it.
The monolith was killed by: developers who hadn’t asked “what worked before this?”
“Everyone was wrong in different ways that averaged out to correct.”
“That’s enterprise middleware.”
— The Schrödinger IP
The Squirrel loved the ESB for the same reason it loves microservices, Redis, Kubernetes, and any sufficiently complex infrastructure: it is interesting. Message routing is interesting. Protocol transformation is interesting. Content-based routing with XPath expressions evaluated against SOAP headers at runtime is fascinating.
None of this is relevant to whether twelve hundred users can check their account balance in under two seconds.
The Data Fabric Precedent
Before Gartner named it, the pattern existed. In 1998, a developer needed 0.4-second response times for variable field data across distributed systems. He built something that solved the problem — a lightweight integration layer, purpose-built, no vendor, no governance model, no bus team.
Four years later, Gartner would name this pattern “Enterprise Service Bus” and an industry would spend the next decade building the enterprise version: slower, more expensive, more governable, and infinitely more presentable in a slide deck.
The difference between solving a problem and productizing the solution is the difference between a developer writing a direct integration in an afternoon and a vendor selling a bus that requires eighteen months of architecture committee to install. The problem was the same. The solution was the same. The invoice was not.
The Transformation Tax
The ESB’s most measurable cost was the transformation tax — the computational and organizational overhead of converting messages between formats as they traversed the bus.
System A speaks XML. System B speaks JSON. System C speaks the proprietary binary format it has spoken since 1994 and will speak until the sun expands. The ESB transforms: XML to canonical format, canonical format to JSON, canonical format to proprietary binary. Each transformation adds latency. Each transformation adds a failure mode. Each transformation requires a mapping document that someone wrote in 2007 and nobody has updated since.
The canonical data model — the “one true format” that all messages pass through — is the ESB’s Premature Abstraction. It is the generic DocumentProcessor<T> of enterprise integration: a universal representation of all possible data, designed before any specific data was understood, maintained by a team that has never met the users of the systems it connects.
A direct integration between System A and System B would have taken an afternoon. Through the ESB, it takes three sprints, a change request, an impact assessment, a review by the integration architecture board, and a prayer.
The Vendor Ecosystem
The ESB spawned a vendor ecosystem of remarkable proportions. IBM had WebSphere ESB. Oracle had Oracle Service Bus. TIBCO had TIBCO BusinessWorks. MuleSoft had Mule ESB. Microsoft had BizTalk. Each vendor sold essentially the same product — a message broker with transformation capabilities — at prices that suggested they were selling something considerably more exotic.
The vendor ecosystem sustained itself through a mechanism familiar from the consulting industrial complex: the product required specialists to configure, the specialists were certified by the vendor, the certification required training from the vendor, and the training was available at prices that made the license look reasonable by comparison.
A developer who could write a direct HTTP call between two services in twenty minutes was replaced by an integration specialist who could configure the same integration through the ESB in three weeks. The twenty-minute solution was “point-to-point” and therefore bad. The three-week solution was “service-oriented” and therefore good. The difference was not technical. The difference was vocabulary.
When the ESB Was Right
The ESB was right when:
- Hundreds of systems genuinely needed to exchange data in dozens of formats
- Regulatory requirements demanded message auditing and governance
- The organization had thousands of developers and could afford a dedicated integration team
- The transformation complexity was genuine, not manufactured by the architecture
- You were a bank, a telecom, or a government, and the mainframe from 1987 was non-negotiable
The ESB was wrong when:
- Two systems needed to talk to each other and someone drew a bus on a whiteboard
- The “enterprise” had twelve developers organized into four tribes
- The transformation layer was converting XML to XML via a canonical model that was also XML
- The bus team had more members than the number of integrations they managed
- The governance model required three weeks of approvals for a change that would have taken twenty minutes without the bus
- Someone said “but what about future integrations?” — the ESB’s version of “what if the sun explodes?”
The Legacy
The ESB is now widely regarded as a cautionary tale. SOA conferences have been replaced by microservices conferences. ESB vendors have rebranded as “integration platform” vendors. The bus has been replaced by the service mesh. The transformation layer has been replaced by the API gateway. The integration architecture board has been replaced by the platform team.
The problems are the same. The vocabulary has changed. The invoices have adjusted for inflation.
Somewhere, a consultant in a slightly-too-casual blazer is staring at a microservices architecture diagram containing forty-seven services, a service mesh, three Kubernetes clusters, and a Redis cache saving eleven milliseconds on queries that take twelve. The consultant is blinking. The consultant is about to ask a question.
The question is the same one that killed the ESB:
“What worked before this?”
