Ein Enterprise Service Bus (ESB) ist eine klassische Enterprise-Integrationsarchitektur, bei der ein zentraler „Bus“ als gemeinsamer Kommunikationskanal zwischen allen Anwendungen eines Unternehmens dient. Alle Systeme verbinden sich mit diesem Bus – anstatt direkt miteinander zu kommunizieren. Der ESB übernimmt Routing, Transformation, Protokollumwandlung, Sicherheit und Monitoring für alle systemübergreifenden Kommunikationen.
Das ESB-Konzept stammt aus den frühen 2000er Jahren und war die dominierende Enterprise-Integrationsarchitektur für ein Jahrzehnt. Mit dem Aufstieg von Cloud, Microservices und API-first-Architekturen verlor der klassische ESB an Relevanz – gilt heute aber noch in vielen Großunternehmen als zentrales Integrations-Backbone, oft parallel zu moderneren iPaaS-Lösungen.
ESB als zentraler Hub
Hub-and-Spoke: alle Systeme sprechen mit dem ESB
Enterprise Service Bus
SAP ERPSalesforceLegacy-SystemHR-SystemWebshopEDI-Partner
Kernfunktionen eines ESB
- Message Routing: Der ESB entscheidet, welches Zielsystem eine Nachricht empfangen soll – basierend auf Inhalt, Absender oder Regeln
- Protokollumwandlung: System A spricht SOAP/XML, System B erwartet REST/JSON – der ESB übersetzt zwischen Protokollen und Formaten
- Nachrichtentransformation: Daten werden im ESB in das Format des Empfängers umgewandelt – Felder gemappt, Strukturen angepasst
- Orchestrierung: Der ESB kann komplexe Prozessflüsse koordinieren, die mehrere Systeme in definierter Reihenfolge ansprechen
- Service Registry: Alle verfügbaren Services und ihre Schnittstellen sind zentral im ESB registriert und auffindbar
ESB heute: Stärken und Grenzen
Der klassische ESB ist in stabilisierten Enterprise-Umgebungen mit komplexen Legacy-Integrationen nach wie vor ein solides Fundament – er beherrscht Protokollumwandlungen und Nachrichtenverarbeitung, die moderne iPaaS-Tools nicht immer abbilden. In agilen, cloud-nativen Umgebungen ist er hingegen zu schwerfällig: lange Implementierungszeiten, hohe Betriebskomplexität und Abhängigkeit von spezialisiertem Wissen machen ihn zum Bottleneck statt zur Lösung. Viele Unternehmen betreiben heute beide Schichten parallel – ESB für Legacy-Kernintegrationen, iPaaS für neue, agile Verbindungen.
Praxisbeispiel
Ein Versicherungskonzern betreibt seit 2008 einen IBM MQ-basierten ESB, der die Kernintegration zwischen Bestandssystem, Schadensystem und Zahlungsabwicklung sicherstellt – 40 definierte Integrationen, hochstabil, vollständig auditiert. Neue digitale Initiativen (Kundenportal, App, Chatbot) werden nicht mehr über den ESB entwickelt – die Implementierungszeiten von 6–12 Monaten pro Integration sind mit der agilen Produktentwicklung unvereinbar. Stattdessen wird Make als ergänzende iPaaS-Schicht eingeführt: Neue Integrationen entstehen in Tagen, der ESB bleibt unangetastet für seinen bewährten Kernbereich. Zwei Generationen, eine Integrationslandschaft.
