Wann Middleware nötig ist — und wann nicht

Der Begriff Middleware klingt nach großer Architektur, meint aber etwas sehr Handfestes: eine Schicht, die zwischen zwei oder mehr Systemen sitzt und den Datenverkehr zwischen ihnen vermittelt. Statt dass die Warenwirtschaft direkt in die Datenbank des Versandprogramms schreibt, übergibt sie den Vorgang an den Vermittler. Der nimmt an, prüft, übersetzt, merkt sich den Vorgang und reicht ihn an das Zielsystem weiter. Ist das Zielsystem gerade nicht erreichbar, wartet der Vermittler und versucht es später erneut, statt den Datensatz zu verlieren.

Damit übernimmt die Zwischenschicht vier Aufgaben, die sonst in jeder einzelnen Verbindung erneut gebaut werden müssten: die Übersetzung zwischen unterschiedlichen Formaten, die Zwischenspeicherung, damit Sender und Empfänger nicht im selben Moment verfügbar sein müssen, die Wiederholung fehlgeschlagener Übertragungen ohne doppelte Buchung und die Protokollierung an einer Stelle. Der letzte Punkt wird in Angeboten oft übergangen und ist im Alltag der entscheidende. Wer wissen will, warum ein Auftrag nicht im Lager angekommen ist, schaut dann an einer Stelle nach statt in fünf Systemen.

Wichtig ist die Abgrenzung: Middleware ist weder ein bestimmtes Produkt noch eine bestimmte Technik. Sie kann ein eigenständiger Dienst auf dem eigenen Server sein, ein Warteschlangensystem, ein Integrationsdienst beim Anbieter oder ein selbst geschriebenes Programm, das nachts Dateien abholt, umformt und weiterreicht. Entscheidend ist nicht die Bauform, sondern die Frage, ob der Datenverkehr an einer definierten Stelle zusammenläuft, an der er sichtbar, wiederholbar und nachvollziehbar ist.

Die Grenze liegt weniger bei einer bestimmten Zahl von Systemen als bei der Zahl der Verbindungen zwischen ihnen. Sollen alle Systeme untereinander Daten austauschen können, wächst diese Zahl nach der Formel n mal (n minus 1) geteilt durch zwei. Drei Systeme ergeben 3 Verbindungen, fünf Systeme 10, acht Systeme bereits 28 (Rechenbeispiel). In der Praxis tauscht selten jedes System mit jedem Daten aus, die tatsächliche Zahl liegt also niedriger. Die Richtung bleibt aber dieselbe: Jedes zusätzliche System bringt mehr neue Verbindungen mit, als es selbst Systeme sind.

Der praktische Kipppunkt tritt meist früher ein, als die Formel vermuten lässt. Er kommt in dem Moment, in dem dieselben Daten von mehr als zwei Systemen gebraucht werden. Sobald eine Kundenadresse in der Warenwirtschaft, im Auftragssystem, im Versandprogramm und in der Buchhaltung stehen muss, entsteht bei Punkt-zu-Punkt-Verbindungen ein Geflecht, in dem eine Änderung an einer Stelle vier andere Stellen betrifft. Wer dann ein System austauscht, muss jede einzelne Verbindung anfassen.

Der zweite typische Auslöser ist die Fehlersuche. Solange jede Verbindung ihr eigenes Protokoll führt — eine in einer Textdatei, eine in einer Datenbanktabelle, eine gar nicht — dauert die Beantwortung der Frage „Wo ist der Auftrag hängengeblieben?" länger als die Korrektur selbst. Erfahrungsgemäß ist das der Punkt, an dem Betriebe von sich aus nach einer Zwischenschicht fragen: nicht wegen der Architektur, sondern weil das Suchen zu viel Zeit kostet (Projekterfahrung).

Eine Zwischenschicht transportiert und übersetzt, sie repariert aber keine schlechten Daten. Wenn im Auftragssystem drei Schreibweisen desselben Kunden stehen, entstehen mit Vermittler drei Datensätze im Zielsystem statt zwei — schneller und zuverlässiger als vorher, aber ebenso falsch. Stammdatenpflege und die Klärung, welches System für welches Feld führend ist, bleiben Aufgaben der Datenintegration und gehören vor die technische Umsetzung.

Ebenso wenig ersetzt ein Vermittler fachliche Entscheidungen. Ob ein Auftrag ohne Bonitätsprüfung in den Versand darf, ob eine Rechnung nach Teillieferung sofort erzeugt wird, ob Stornierungen rückwirkend gebucht werden dürfen: Das sind Regeln des Betriebs, keine Fragen der Übertragungstechnik. Werden sie ungeklärt in die Zwischenschicht verlagert, entsteht dort mit der Zeit eine zweite, undokumentierte Fachlogik neben den eigentlichen Systemen — und die ist später schwerer zu ändern als jede Schnittstelle.

Die Entscheidung für oder gegen eine Zwischenschicht lässt sich mit wenigen Fragen deutlich versachlichen. Sie sollten schriftlich beantwortet werden, bevor über Technik gesprochen wird — im Rahmen einer Prozessanalyse oder in einer eigenen Runde mit den Menschen, die die betroffenen Abläufe täglich ausführen.

Die Antworten auf die Fragen eins bis vier zeigen, ob der Bedarf da ist. Die Antworten auf fünf und sechs entscheiden darüber, ob die Lösung im Betrieb trägt. Ein Vorhaben, bei dem die letzten beiden Fragen offen bleiben, sollte verschoben werden, bis sie beantwortet sind.

Der Nutzen einer Zwischenschicht entsteht im Betrieb, nicht bei der Einführung. Dafür braucht es zwei Dinge: ein Protokoll, das eine fachlich zuständige Person lesen kann, und eine Benachrichtigung, die jemanden erreicht, bevor der Kunde anruft. Ein brauchbares Protokoll führt je Vorgang eine eindeutige Kennung mit, damit sich eine Übertragung über mehrere Systeme hinweg verfolgen lässt.

An diesem Beispiel wird der Unterschied zwischen den drei relevanten Zuständen sichtbar: „ok" braucht keine Aufmerksamkeit, „fehler" wird automatisch wiederholt und meldet sich nur, wenn die Wiederholungen erschöpft sind, „abbruch" braucht eine Person, weil die Daten selbst unvollständig sind. Diese Unterscheidung entscheidet darüber, ob eine Überwachung hilfreich ist oder nach zwei Wochen ignoriert wird.

Ebenso wichtig ist der geplante Wiederanlauf. Nach einem Ausfall des Vermittlers muss klar sein, ob offene Vorgänge automatisch nachlaufen oder manuell angestoßen werden, und wie erkannt wird, ob dabei etwas doppelt zugestellt wurde. Diese Fragen gehören in den laufenden IT-Betrieb und sollten vor der ersten Störung schriftlich beantwortet sein, nicht während der ersten Störung.