Die IT-Landschaft neu aufbauen: Schritt-für-Schritt-Migration zu Microservices-Architekturen

Um wettbewerbsfähig zu bleiben, müssen Unternehmen ihre IT agil aufstellen. Microservices, oder auch generell kleinere Einheiten mit klaren APIs, sind hierbei ein wichtiger Baustein. Doch wie kann ein Monolith schrittweise modernisiert werden? Hier kann ein Blick auf die Geschäftsprozesse helfen.
Die IT-Infrastruktur und -Architektur eines Unternehmens spielen eine wesentliche Rolle für den wirtschaftlichen Erfolg und die Fähigkeit, sich schnell an veränderte Rahmenbedingungen anzupassen. In vielen Unternehmen ist die Einsicht gewachsen, dass traditionelle monolithische Anwendungen diese Voraussetzung nicht mehr erfüllen. Im ersten Teil dieser Serie habe ich schon genauer beschrieben, warum Microservices hierfür eine beliebte Option darstellen.
Ein Ziel vor Augen zu haben, ist eine Sache – aber den Weg dorthin zu definieren, ist eine ganz andere. Big-Bang-Migrationen der kritischsten Unternehmensanwendungen sind so gut wie nie erfolgreich, also stellt sich die Frage, wie man eine solche Migration in sinnvolle Häppchen aufteilen kann.
Ein Weg, der sich bei vielen Kunden bewährt hat, ist, sich an den Geschäftsprozessen entlang zu hangeln. Geschäftsprozesse orientieren sich sehr konkret an Kundenbedürfnissen und deren Erfüllung, sprich der Customer Experience, die heute für alle Unternehmen wichtig ist. Daher ist es gerade in Migrationsszenarien relevant, diese Prozesse im Auge zu behalten, damit sie stets reibungslos funktionieren und nicht auf einmal kaputt gehen [1]. Ein Monitoring ist außerdem ratsam, damit Prozesse stetig verbessert werden können.
Der Ist-Zustand: Spaghetti-Integration
Nehmen wir eine Bank als Beispiel, die bisher mit viel Legacy-Software zu kämpfen hatte. Will ein Kunde heute ein Konto eröffnen, müssen ihm verschiedene Kanäle angeboten werden (die sogenannte "Omnichannel Experience"). Das heißt, der Kunde möchte gerne online sein Konto eröffnen können und nicht physisch einen Papierantrag in einer Filiale abgeben müssen (oder gar ein Fax senden). Die eigentliche Abwicklung der Kontoeröffnung ist aber eine wilde Integration der bestehenden Systeme, ohne einen klaren Überblick und meist in Legacy-Systemen irgendwo unter der Haube versteckt. Ich nenne das gerne "Spaghetti-Integration". Und wie bei einem Teller dampfender Spaghetti ist es schwer, einem einzelnen Strang genau zu folgen.
Gibt es in dieser Situation neue Anforderungen – zum Beispiel, dass Kunden nicht mehr bereit sind, tagelang auf ihre Kontoeröffnung zu warten oder die Compliance erfordert, neue Prüfungen in den Prozess zu integrieren – wird es schwierig. Denn im Haufen der Spaghetti weiß man nicht, wo man Änderungen eigentlich einbauen kann und soll, und welche Auswirkungen diese Änderungen mit sich bringen.
Ein erster Schritt: Process Tracking
Es ist daher sinnvoll, den Prozess zunächst zu visualisieren, um ihn für verschiedene Stakeholder nachvollziehbar zu machen und dann einer geeigneten Software zu übergeben. Process-Orchestration-Plattformen können zum Beispiel im Standard BPMN (Business Process Model and Notation) modellierte Prozesse direkt ausführen [2]. Abb. 1 zeigt ein Beispiel eines möglichen Modells für die Kontoeröffnung.
Typischerweise wird mit solchen Prozessmodellen ein Geschäftsprozess direkt gesteuert, daher heißen diese Tools auch "Process Orchestrator". Das bedeutet, dass ein Task einen bestimmten Endpunkt im Prozess einbindet, also zum Beispiel eine API aufruft oder einem Menschen eine Aufgabe ins Postfach legt.
Allerdings stellt sich die Frage, wie man diese Orchestrierungskomponente einführen kann. Denn im bestehenden Legacy-System wird der Prozess bereits gesteuert, allerdings nur implizit durch die Spaghetti oder durch manuelle Tätigkeiten und das ist meist nicht nachvollziehbar. Diese implizite Steuerung können wir nicht auf einen Schlag ausbauen. Um den Prozess zumindest nachvollziehbar zu machen, können wir aber Ereignisse aus dem bestehenden Teller Spaghetti mitlesen, um im Orchestrator Prozessinstanzen zu starten oder weiterzuschieben. Wir sprechen dann von Process Tracking: Der Prozess wird quasi zum Zwilling des legacy-integrierten Prozesses.
Dieser Schritt ist erfahrungsgemäß mit wenig Aufwand verbunden und birgt kein Risiko, da nicht in die Implementierung des Prozesses eingegriffen wird. Gleichzeitig hat das Vorgehen aber sofort relevante Vorteile: Durch die Visualisierung verstehen Stakeholder besser, wie der Prozess aktuell abläuft. Das Mapping der Ereignisse validiert dabei, ob das Prozessmodell nur eine Wunschvorstellung oder Realität ist. Die Orchestration Platform liefert dann sofort Metriken, wie Liege- oder Durchlaufzeiten und kann Hinweise auf Probleme oder Flaschenhälse liefern – und somit trotz des Spaghetti-Dickichts sichtbar machen, wo es vielleicht hakt oder länger dauert als nötig. Zusätzlich können auch einzelne Instanzen überwacht werden, damit es auffällt, wenn ein Prozess aus irgendeinem Grund nicht mehr weiterläuft. Beispielsweise dauerte meine letzte Kontoeröffnung bei der Bank sechs Wochen und bedurfte vieler Nachfragen meinerseits – da fragt man sich als Kunde schon, was denn da so viel Zeit in Anspruch nimmt. Doch weiß das die Bank überhaupt selbst?
Offen für Änderungen
In einigen Fällen können Unternehmen vielleicht auch mit Process Mining arbeiten. Aber der große Vorteil des Process Trackings ist, dass in den Prozessen direkt Änderungen eingebracht werden können.
Zum Beispiel könnte man schon direkt einen API-Aufruf in das Modell einbringen, der den Kunden in ein neues KYC-(Know-Your-Customer-)System einträgt [3]. Dafür muss man nicht mehr in den vollen Teller Spaghetti fassen, sondern kann dies im Orchestration-Tool umsetzen.
Schritt für Schritt zur Orchestrierung
Natürlich ist das nur der erste Schritt. Das eigentlich Spannende ist, dass auf dieser Basis eine graduelle Transformation, weg von Spaghetti, hin zu orchestrierten (Micro-)Services möglich ist. Dabei kann man sich jetzt von Metriken des Prozesses (z. B. "Wir verlieren die meiste Zeit bei Schritt X.") oder auch fachlichen Schmerzen (beispielsweise "Wir müssen dringend die Automatisierungsquote erhöhen, um das anvisierte Wachstum zu schaffen.") leiten lassen.
In jedem Fall gilt es nun, eine Aufgabe im Prozess herauszusuchen und diese vom reinen Tracking auf Orchestrierung umzustellen. Dazu bedarf es typischerweise mehrerer Schritte:
- Die implizierte Integrationslogik, die diese Aufgabe bisher im Spaghetti-Modell ausgeführt hat, muss entfernt werden. Nur so kann die Aufgabe dann zielgerichtet vom Orchestrator angesteuert werden.
- Die Funktionalität muss eine geeignete Schnittstelle bekommen und abrufbar gemacht werden.
- Die Schnittstelle wird über den Prozess orchestriert.
Dabei ist es unerheblich, ob man eine Systemintegration oder eine menschliche Aufgabe orchestriert. Für die Integration eines Software-Systems gilt es, eine API bereitzustellen und anzubinden; für menschliche Aufgaben werden meist unstrukturierte E-Mails durch Task-Listen und Formulare ersetzt.
Dieses Inkrement kann dann produktiv ausgerollt werden und bringt idealerweise auch direkt einen fachlichen Mehrwert für Customer Experience, Prozesseffizienz oder die Einhaltung von Risiko- und Compliance-Anforderungen. Eine solche Änderung ist nicht unbedingt trivial, aber immer noch mit geringem Risiko durchführbar.
Mit der Zeit kann man sich nun Schritt für Schritt von dem Spaghettihaufen trennen und ihn durch Orchestrierung ersetzen, bis man beim jeweiligen Zielbild des Prozesses angekommen ist.
Orchestrierung als Enabler für Experimente
Während dieser Reise zu einer besseren Architektur erlaubt die Prozessorchestrierung übrigens auch, wesentlich einfacher zu experimentieren. Viele unserer Kunden würden zum Beispiel gerne sofort künstliche Intelligenz in ihre Prozesse einbinden. Das oben beschriebene Vorgehen kann den Prozess in einen Zustand bringen, in dem diese Versuche auch an der richtigen Stelle möglich werden. Zum Beispiel, dass in gewissen Szenarien eine KI anstelle eines Mitarbeiters die Risikoabschätzung übernimmt.
Adios Monolith?
Halten wir zum Abschluss die Schritte fest, die uns zum Ziel einer Architektur aus Microservices bzw. kleinen Einheiten mit klaren APIs bringen:
- Den Ist-Zustand erfassen: Liegt eine akute Spaghetti-Integration vor?
- Die Geschäftsprozesse angehen – einen nach dem anderen
- Mit Process Tracking den Prozess als BPMN-Modell abbilden
- Die Messungen mit dem Soll-Zustand vergleichen und Probleme oder Flaschenhälse ausfindig machen
- Relevante Aufgaben implementieren, mit einer Schnittstelle versehen und im Prozessmodell orchestrieren
- Inkrementell testen und wiederholen
Das skizzierte Vorgehen ist bei unseren Kunden sehr beliebt, um die digitale Transformation möglichst risikofrei voranzutreiben. Erste Schritte können sehr einfach gegangen werden. Natürlich bleiben meist ein paar Reste wirrer Nudeln auf dem Teller, aber das ist verschmerzbar, denn die erhöhte Agilität und die verbesserte Customer Experience kommen der Wettbewerbsfähigkeit schon ab dem ersten Schritt zugute.