Enterprise service bus (ESB)

An enterprise service bus is a central piece of middleware that connects applications. Instead of each system integrating directly with every other, they all connect to the bus, which routes messages, transforms formats, translates protocols and sometimes orchestrates multi-step processes.

ESBs were the backbone of service-oriented architecture in the 2000s and still run critical integrations in many large enterprises.

Diagram

flowchart LR
    crm[CRM] <--> bus
    erp[ERP] <--> bus
    legacy[Mainframe] <--> bus
    portal[Customer portal] <--> bus
    bus{{"Enterprise service bus<br/>routing, transformation,<br/>protocol mediation"}}
    bus <--> partner[Partner via SFTP]

How it works

• Hub-and-spoke. Each application connects once, to the bus, instead of to every other application.
• Message routing. The bus decides where a message goes based on its content or type.
• Transformation. It converts between formats, for example from a mainframe flat file to XML or JSON.
• Protocol mediation. It bridges protocols such as SOAP, REST, JMS, FTP and file drops.
• Orchestration. Some ESBs coordinate multi-step business processes across systems.

Pros

• Fewer point-to-point connections: N systems need N connections, not N×(N−1).
• Connects legacy systems: adapters for old protocols and formats are built in.
• Central monitoring and control of integration traffic.
• Reusable transformations and connectors.

Cons

• Central bottleneck: one integration team and one platform must handle every change.
• Smart pipes: business logic creeps into the bus, where it’s hard to test and own.
• Single point of failure: an outage affects every connected system.
• Heavyweight: licensing, specialist skills and slow change cycles.

When to use it

• Large enterprises with many legacy systems, varied protocols and existing ESB investment.
• Integrations that need heavy protocol and format mediation.

When to avoid it

• New, cloud-native systems where teams own their own integrations. Consider API-led connectivity or messaging.
• When the bus would become the place where business rules live.

Common pitfalls

• Putting business logic in the bus. Keep the bus for routing and transformation; keep rules in the applications that own them.
• One central team for all integrations, which turns the bus into the organization’s slowest queue.
• Canonical data models that try to fit everyone, growing until no one can change them.

Related patterns

• API-led connectivity
• Message queues and publish/subscribe
• Service-oriented architecture (SOA)
• Enterprise integration patterns

Further reading

• Gregor Hohpe and Bobby Woolf, Enterprise Integration Patterns
• David Chappell, Enterprise Service Bus