Hub and Spoke
Viele Systeme über eine Zentrale verbinden
Die Idee und ihr Nutzen
Eine Versicherung erhält Daten von vielen Partnern: Werkstätten schicken Kostenvoranschläge, Gutachter Berichte, Mietwagenfirmen Rechnungen und Banken Zahlungsbestätigungen. Jeder dieser Partner liefert seine Daten in einem anderen Format. Im Schadensystem bearbeitet die Versicherung die Schadenfälle. Statt dass das Schadensystem zu jedem Partner eine eigene Verbindung pflegt, schließt die Versicherung alle Partner an eine gemeinsame Partnerzentrale an. Die Partnerzentrale ist ein eigenes Programm, das die Daten annimmt, in ein einheitliches Format übersetzt und an das Schadensystem weiterleitet. Ein neuer Partner braucht dann nur eine Verbindung zur Partnerzentrale. Diese sternförmige Anordnung heißt Hub and Spoke, auf Deutsch Nabe und Speiche. Die Partnerzentrale ist dabei die Nabe, und die Verbindungen der Partner sind die Speichen.
Wie funktioniert es?
An einem Montag sendet eine Werkstatt der Partnerzentrale einen Kostenvoranschlag über 2.300 Euro für einen Kfz-Schaden. Die Werkstatt schickt ihn als Datei in ihrem eigenen Format. Ein Gutachter schickt seinen Bericht über eine Webschnittstelle, also als Aufruf über das Internet. Eine Bank bestätigt eine Zahlung in ihrem Bankformat. Genauso angebunden wäre eine Mietwagenfirma, die ihre Rechnung als PDF mit einer Datendatei schickt. Die Partnerzentrale erkennt die Art jeder Nachricht und damit ihren Empfänger, hier das Schadensystem. Dann übersetzt die Partnerzentrale jede Nachricht in das einheitliche Format und leitet sie an das Schadensystem weiter. Das Schadensystem ist nur mit der Partnerzentrale verbunden, erhält von ihr alle Nachrichten im selben Format und ordnet jede dem richtigen Schadenfall zu. Ein anderes Format als das einheitliche kann das Schadensystem nicht verarbeiten. Einige Monate später kommt ein neuer Gutachterverbund hinzu, der Berichte in einem wieder anderen Format liefert. Das Team, das die Partnerzentrale betreut, richtet in der Partnerzentrale eine neue Anbindung mit einer Übersetzung für dieses Format ein. Die Verbindung zwischen Partnerzentrale und Schadensystem bleibt unverändert, weil das einheitliche Format alle Angaben eines Gutachterberichts schon vorsieht.
Die Partner sind eigenständige Unternehmen mit eigenen Programmen. Jeder Partner legt selbst fest, in welchem Format er Daten schickt und ob als Datei oder über eine Webschnittstelle. Die Versicherung kann das nicht vorschreiben. Beim Anschluss eines Partners an die Partnerzentrale wird deshalb einmal festgehalten, welche Daten er in welchem Format sendet oder empfängt. Das einheitliche Format dagegen legt die Versicherung einmal für alle Partner fest. Es beschreibt zum Beispiel, welche Angaben ein Kostenvoranschlag oder ein Gutachterbericht enthält, unabhängig vom Absender. Die Partnerzentrale muss alle Formate der Partner und alle Empfänger kennen und jede Übertragungsart der Partner unterstützen, also Dateien ebenso wie Aufrufe über eine Webschnittstelle. Fachlich entscheidet sie nichts, etwa ob eine Rechnung bezahlt wird. Technisch kann die Partnerzentrale eine Integrationsplattform sein, also ein fertiges Produkt zum Verbinden von Programmen. Sie kann auch eine Nachrichtenplattform sein, die Nachrichten von einem Programm annimmt und an andere Programme verteilt, oder ein eigens entwickeltes Programm.
Ist das Schadensystem gerade nicht erreichbar, muss die Partnerzentrale die übersetzten Nachrichten aufbewahren und später zustellen. Dass ein Partner seine Nachricht erfolgreich an die Partnerzentrale geschickt hat, heißt also noch nicht, dass das Schadensystem sie schon erhalten hat. Enthält der Bericht eines neuen Partners eine Angabe, die im einheitlichen Format fehlt, reicht eine neue Anbindung nicht. Dann muss das Format erweitert und das Schadensystem angepasst werden.
Hub and Spoke: die Partnerzentrale übersetzt für das Schadensystem
Wann ist es sinnvoll und wann nicht?
Hub and Spoke lohnt sich
- Viele Systeme tauschen miteinander Daten aus. Ohne Partnerzentrale braucht jedes Paar von Systemen, das Daten austauscht, eine eigene direkte Verbindung mit eigenem Format, eigener Adresse und eigener Fehlerbehandlung. Tauscht jedes von vier Systemen mit jedem anderen Daten aus, sind das sechs Verbindungen. Bei zehn Systemen wären es bis zu 45. In der Praxis sind es meist weniger, weil nicht jedes System mit jedem anderen Daten austauscht.
- Mehrere Partner sollen dieselben Empfänger erreichen. Ohne Partnerzentrale pflegt das Schadensystem je eine Verbindung zu Werkstätten, Gutachtern, Mietwagenfirmen und Banken. Tauschen auch andere Systeme Daten mit diesen Partnern aus, kommen weitere direkte Verbindungen hinzu. So tauscht zum Beispiel auch das Buchhaltungssystem Daten mit den Banken aus. Mit Partnerzentrale haben Schadensystem und Buchhaltungssystem je nur eine Verbindung, nämlich zur Partnerzentrale.
- Partner ändern ihr Format oder ihre Adresse. Ohne Partnerzentrale muss dann jedes System angepasst werden, das direkt mit dem betroffenen Partner verbunden ist. Mit Partnerzentrale wird nur die Anbindung dieses Partners an die Partnerzentrale angepasst.
- Partner kommen häufig hinzu oder wechseln, während das Schadensystem und das Buchhaltungssystem über Jahre dieselben bleiben. Das Schadensystem und die anderen Partner müssen für einen neuen Partner nichts ändern, solange das einheitliche Format die Angaben des neuen Partners bereits abdeckt. Ohne Partnerzentrale müsste das Team des Schadensystems für jeden neuen Partner eine eigene Verbindung und eine eigene Übersetzung in das Schadensystem einbauen.
- Die Versicherung will wissen, welche Daten wohin fließen. Ohne Partnerzentrale muss dafür jemand die Einstellungen jeder einzelnen Verbindung in jedem System durchsehen. Mit Partnerzentrale steht in den Anbindungen der Partnerzentrale an einem Ort, welcher Partner welche Daten an welches System schickt.
Hub and Spoke ist nicht das Richtige
- Es gibt nur wenige Partner, und ihre Verbindungen ändern sich selten. Dann richtet das Team des Schadensystems für jeden Partner eine eigene direkte Verbindung ein und baut die Übersetzung des Partnerformats in das Schadensystem ein. Bei drei Partnern sind das drei Verbindungen; mit Partnerzentrale wären es drei Verbindungen zur Partnerzentrale und eine weitere zum Schadensystem. Ein zusätzliches Programm, das betrieben und gepflegt werden muss, entfällt.
- Das Team des Schadensystems und das Team des Buchhaltungssystems sollen ihre Anbindungen an die Partner unabhängig voneinander ändern können. Mit Partnerzentrale läuft jede neue Anbindung über das Team der Partnerzentrale. Will das Team des Buchhaltungssystems eine neue Bank anbinden, wartet es womöglich, bis das Team der Partnerzentrale eine Anbindung für das Schadensystem fertig hat. Stattdessen verbindet jedes der beiden Teams sein System selbst direkt mit den Partnern, die es braucht. Dafür pflegt jedes der beiden Teams die Übersetzung der Partnerformate selbst, und das Bankformat wird im Schadensystem und im Buchhaltungssystem je einmal übersetzt.
- Auch Schadensystem und Buchhaltungssystem sollen untereinander Nachrichten austauschen, und ein Programm soll Abläufe über mehrere Programme steuern. Die Partnerzentrale übersetzt nur die Nachrichten der Partner und entscheidet nichts über Abläufe. Die Versicherung bräuchte dafür also eine zweite Plattform. Stattdessen setzt die Versicherung einen Enterprise Service Bus ein, ein gemeinsames Programm, an das jedes Programm der Versicherung seine Nachrichten schickt und das sie umwandelt und an den Empfänger weiterleitet. Das Team, das den Enterprise Service Bus betreut, richtet auch die Anbindungen der Partner darin ein. Eine zweite Plattform nur für die Partner muss dann niemand betreiben.
- Partnernachrichten sollen an mehrere Empfänger gehen, die sich selbst für diese Nachrichten anmelden. Die Zahlungsbestätigungen der Banken braucht zum Beispiel auch das Buchhaltungssystem. Die Partnerzentrale muss jeden Empfänger kennen, und für jeden neuen Empfänger muss das Team der Partnerzentrale die Partnerzentrale ändern. Stattdessen übergibt die Partnerzentrale jede Nachricht an eine Nachrichtenplattform, wie es Publish Subscribe beschreibt. Jedes System, das sich für diese Art von Nachricht angemeldet hat, erhält sie. Kommt ein neuer Empfänger hinzu, meldet er sich selbst an, und die Partnerzentrale muss dafür nicht geändert werden.
Nachteile und typische Fehler
Alle Partnerverbindungen hängen an der Partnerzentrale. Der Betrieb mehrerer Exemplare derselben Partnerzentrale auf verschiedenen Servern, der Wiederanlauf nach einem Ausfall und die erneute Zustellung liegen gebliebener Nachrichten müssen deshalb geplant werden. Fällt ein Server aus, nehmen die Exemplare auf den übrigen Servern die Nachrichten der Partner weiter an. Mit der Zahl der Partner wächst die Zahl der Nachrichten, die die Partnerzentrale in derselben Zeit annehmen und übersetzen muss. Das einheitliche Format muss die Versicherung jedes Mal erweitern, wenn ein Partner eine Angabe liefert, die darin noch fehlt. Jede neue Anbindung läuft über das Team der Partnerzentrale. Hat das Team der Partnerzentrale zu wenig Zeit, warten das Team des Schadensystems und das Team des Buchhaltungssystems auf seine Arbeit.
Typische Fehler und woran man sie erkennt:
- Ausfall der Partnerzentrale: Die Partnerzentrale läuft nur als ein einziges Exemplar auf einem Server. Fällt dieser Server aus, nimmt niemand mehr die Nachrichten der Partner an. Kein Kostenvoranschlag und keine Zahlungsbestätigung erreicht dann das Schadensystem. Erkennbar ist das daran, dass gleichzeitig keine Nachrichten von irgendeinem Partner mehr eingehen.
- Überlastung: Nach einem Hagelsturm schicken Werkstätten und Gutachter an einem Tag zehnmal so viele Kostenvoranschläge und Berichte wie sonst. Die Partnerzentrale übersetzt in einer Stunde weniger Nachrichten, als in derselben Stunde eintreffen. Die unbearbeiteten Nachrichten stauen sich in der Partnerzentrale. Die Zahlungsbestätigungen der Banken warten in derselben Reihe wie die Kostenvoranschläge und Berichte und kommen deshalb ebenfalls verspätet beim Schadensystem an. Erkennbar ist das an einer wachsenden Zahl unbearbeiteter Nachrichten in der Partnerzentrale.
- Fachregeln in der Partnerzentrale: Das Team der Partnerzentrale baut nach und nach fachliche Entscheidungen in die Übersetzungen ein, etwa welche Rechnungen automatisch bezahlt werden. Über diese Regel entscheidet die Schadenabteilung, programmiert ist sie aber in der Partnerzentrale, die ein anderes Team betreut. Die Partnerzentrale sollte nur annehmen, übersetzen und weiterleiten. Erkennbar ist der Fehler daran, dass fachliche Änderungen der Schadenabteilung Änderungen in der Partnerzentrale erfordern.
- Verlorene Angaben: Ein Partner liefert eine Angabe, die das einheitliche Format nicht vorsieht, und die Übersetzung lässt sie ohne Meldung weg. Erkennbar ist das an Rückfragen von Sachbearbeitern nach Angaben, die der Partner nach eigener Aussage geschickt hat.
Weiterführend
Verwandte Ansätze
- Broker Pattern: beschreibt ein Vermittlungsprogramm, das eine Anfrage an das passende Programm weiterleitet und dessen Antwort zurückgibt.
- Message Translator: beschreibt die Übersetzung einer Nachricht in das Format des Empfängers, wie sie die Partnerzentrale vornimmt.
- Point to Point Channel: ein Nachrichtenkanal mit genau einem Empfänger, über den zum Beispiel ein Partner seine Nachrichten an die Partnerzentrale schicken kann.
Werkzeuge und Umsetzungen
- Apache Camel: Bibliothek mit mehreren hundert Anbindungen an Systeme und Übertragungswege, mit der sich Verbindungen und Formatumwandlungen einer Partnerzentrale bauen lassen.
- Apache NiFi: verwaltet Datenflüsse und Formatumwandlungen über eine grafische Oberfläche.
- WSO2 Micro Integrator: Integrationsplattform, die Anwendungen verbindet und Weiterleitung sowie Formatumwandlung übernimmt.
- RabbitMQ: Nachrichtenplattform, die Nachrichten von angeschlossenen Anwendungen annimmt und an andere angeschlossene Anwendungen verteilt. Die Formatumwandlung muss ein zusätzliches Programm übernehmen.
Quellen
- Gregor Hohpe, Bobby Woolf: Message Broker: beschreibt ein Vermittlungsprogramm, das Nachrichten vieler Absender annimmt und weiterleitet, nennt es auch Hub and Spoke und warnt davor, dass es zum Engpass werden kann.
- Gregor Hohpe, Bobby Woolf: Canonical Data Model: beschreibt das einheitliche Format, in das jede Anwendung nur einmal übersetzt, und zeigt, ab wie vielen Beteiligten es weniger Übersetzungen braucht als direkte Verbindungen.
- Gregor Hohpe, Bobby Woolf: Enterprise Integration Patterns: Buch von 2003, aus dem beide Muster stammen, mit einem Kapitel zur Umwandlung von Nachrichten.