Relevanz eines Enterprise Service Bus

Architektur/Methoden  –  7 Kommentare

Das Thema Enterprise Service Bus hat sicherlich seine Hype-Phase hinter sich. Trotzdem stehen Unternehmen weiterhin vor essenziellen Fragen: Ist ein ESB eher ein Problem oder eher eine Hilfe bei der Lösung von Integrationsproblemen? Können nur große Firmen Nutzen aus ihm ziehen? Eine kritische Auseinandersetzung.

Bevor man sich mit (der vermeintlichen) Lösung ESB befasst, sollte man erst mal das zugrunde liegende Problem suchen. Wer in einer angesagten Web-2.0-Firma arbeitet, findet es unter Umständen nicht, da dort alles frisch mit den neuesten Techniken entwickelt wird. Entweder existiert nur eine große Anwendung (das monolithische Legacy-System von morgen) oder alle Anwendungen sind modern per RESTful Webservice gekoppelt (das Integrationsproblem von morgen). Diese schöne neue Welt bricht dann zusammen, wenn die Buchhaltung ein bewährtes, altmodisches System kauft, das per gar nicht mehr so frischem SOAP angesprochen werden möchte. Oder der Geschäftspartner verlangt den Austausch von XML-Dateien.

Mitarbeiter in "gesetzteren" Firmen werden über solche Luxusprobleme eher lächeln. Dort findet man Dinge wie einen IBM-Host im Keller, der sich gerne per MQSeries unterhält. Und das nicht in JSON oder XML, sondern in Records fester Länge. (Wer kennt alles den Cobol-Begriff Copy-Strecke?)

Ist eine IT-Landschaft so richtig schön historisch gewachsen, findet man n Systeme, die alle miteinander kommunizieren. Schon der junge Gauß hat berechnet, dass man so auf n*(n-1)/2 Verbindungen kommt. Dazu nutzen die Systeme unterschiedliche Übertragungstechniken und keine einheitliche Syntax. Das Verbindungsspaghetti darf man daher noch mit einer quadratischen Anzahl von Adaptern würzen. Willkommen in der Integrationshölle!

Das Marketingversprechen

Nun ist Zeit für das Marketing, das alle Probleme mit einem ESB lösen will: In einer animierten Präsentation verschwindet das Spaghettiknäuel, stattdessen erscheint ein leuchtender Balken mit den drei magischen Buchstaben "ESB". Schön anzusehende, parallele Verbindungen laufen von den einzelnen Systemen zum Balken. Problem scheinbar gelöst – noch nicht alle überzeugt?

Das Marketing verspricht, dass sein Produkt alle Kommunikationstechniken kennt. Wer einen Service anbietet, setzt ihn in den Bus. Der Konsument kann sich den Service auf der anderen Seite in der von ihm gewünschten Technik abholen. Falls ein Adapter notwendig ist, wird er in einer grafischen Oberfläche schnell zusammengeklickt. Das ist nicht schwieriger, als Babelfische zu züchten. Großes Marketing-Ehrenwort: Die Einführung ist auch ganz einfach – kurz die Adapter wegwerfen, alle Systeme anschließen, fertig.

Die bittere Realität

Wer schon mal ein IT-Projekt in einem großen Unternehmen miterlebt hat, weiß, dass die Realität anders aussieht. Hier ändert man nicht gleichzeitig alle Systeme, erst recht nicht "so nebenbei". Selbst wenn das technisch alles kein Problem wäre, würde es nicht funktionieren: Hinter Systemen stehen immer Stakeholder. Für sie ist ihr System am wichtigsten für das ganze Unternehmen, alle anderen haben sich daher grundsätzlich an ihren Zeitplan zu halten, wenn es um neue Releases geht. Das politische Problem, mehrere Abteilungen mit teilweise gegensätzlichen Ansichten zur Zusammenarbeit zu bewegen, sollte man nicht unterschätzen. Das Risiko, mit einem IT-Projekt zu scheitern, steigt durch die notwendige Zusammenarbeit mehrerer Fach- und IT-Abteilungen.

Da helfen auch die Marketing-Versprechen des ESB-Herstellers nur bedingt. Glaubt man ihnen blind, kann man nach ein paar Jahren unternehmensinterner Querelen sicher sein, die Welt um ein weiteres gescheitertes Projekt bereichert zu haben. Aber ist der ESB dabei der Auslöser? Bevor die Frage beantwortet wird, lohnt ein genauerer Blick hinter die technischen Kulissen des Themas ESB.