Bei der Planung einer digitalen Transformation muss der CTO eines Unternehmens viele Entscheidungen treffen, um den Endzustand zu erreichen. Um das übergeordnete Ziel der Abschaffung eines monolithischen Altsystems zu erreichen, ist eine dieser Entscheidungen, ob ein Brownfield- oder ein Greenfield-Ansatz gewählt werden soll.

Aber das ist die letzte Stufe, und bis dahin ist es noch ein langer Weg. Es gibt eine lange Zeitspanne bis zum erfolgreichen Sunsetting, und es ist durchaus akzeptabel, dass die Systeme auf halbem Wege funktionieren. In der Regel handelt es sich dabei um Brownfield-Systeme, bei denen ein Großteil des monolithischen Altsystems mit einem modernen Stack ummantelt wird.

In diesem Artikel geben wir Ihnen Hinweise, wie Sie den Übergang von einem monolithischen zu einem modernen System erleichtern können, wie Sie eine North-Star-Architektur entwickeln und wie Sie sich bei Bedarf in den verschiedenen Phasen Ihrer digitalen Transformation anpassen können.

Getting Started: Möglichkeiten bewerten

Wenn Sie sich für eine Modernisierung entschieden haben, können Sie verschiedene Wege einschlagen: Umstellung auf ein komplett neues System, Umstellung/Refactoring Ihrer Lösung oder Side-by-Side.

Abbildung: Modernisierungsentscheidungen – GL POV

Ein Großteil der Vordenker zu diesem Thema konzentriert sich auf die erfolgreiche Umgestaltung von Architekturen und neuen Systemen. Es wird jedoch nur sehr wenig über Systeme auf halbem Weg diskutiert. Wenn überhaupt, dann wird eher über die älteren monolithischen/Legacy-Systeme und die Menge an Gepäck gesprochen, die sie mit sich bringen.

Aber Midway-Systeme sind komplex und bringen eine Menge Probleme mit sich. Sie können arbeitsintensiv sein und es gibt eine Menge Unbekannte, die das Budget sprengen können. Wir haben mit vielen Kunden in dieser Phase zusammengearbeitet, in der sich ihre Systeme auf halbem Weg befinden, und haben wichtige Lektionen gelernt, die zu einem reibungsloseren Prozess beitragen.

Viele dieser Kunden haben mit der Erstellung eines Green Field-Systems begonnen, dann aber das Ziel geändert und beschlossen, endgültig bei dem System auf halbem Weg zu bleiben. Dafür gibt es viele Gründe:

• Externe Bedrohungen oder Veränderungen. Die Pandemie ist ein großartiges Beispiel dafür, dass Organisationen Investitionen tätigen mussten, um mit dem Anstieg der Bestellungen während oder nach der Pandemie Schritt zu halten.
• Mangelnde Akzeptanz. Während der Testphase oder der MVP-Einführung kann der Kunde Schwierigkeiten haben, die Akzeptanz und Annahme durch die Benutzer zu erreichen.
• Kostenfaktoren. Das Budget ist erschöpft, und anstatt kein System zu haben, bleiben die Kunden bei einem halbfertigen System, das noch funktioniert. So bleibt das Geld im Fluss, und der Kunde beschließt, die Schlacht zu verlieren, um den Krieg zu einem späteren Zeitpunkt zu gewinnen.

Wir können in der Tat den darunter liegenden Stack modernisieren, bevor das eigentliche Benutzererlebnis gestört wird. Dies ist der Fall, wenn das gesamte monolithische System nicht erdrosselt wird. Es scheint noch am Leben zu sein, während der darunter liegende Motor ersetzt wurde. Die harte Realität solcher Systeme trifft uns hart – sie sind komplexer als früher und mit größerer Dringlichkeit, um auf die andere Seite zu gelangen.

North Star – Architektur

Der Übergang zur North Star-Architektur ist eine Herkulesaufgabe und erfordert große Ausdauer. Darüber hinaus ist ein System auf halbem Weg nur mit größerem Aufwand zu pflegen. Wie können wir uns also von einem solchen Fauxpas lösen?

Hier sind die Schritte, die in der Vergangenheit für uns funktioniert haben. Ein visionärer Unternehmensarchitekt, der das alte und das neue System genau kennt, kann dabei helfen, einen Plan zu erstellen, um dies zu erreichen. Verwenden Sie diese einfachen Schritte, um Ihren Plan zu entwerfen.

1. Fahren Sie mit solchen Zwischensystemen mit Elan fort.

Da die Mittelwegsysteme nicht so schnell verschwinden werden, sollten Sie versuchen, das Leben mit solchen Systemen erträglicher zu machen. Investieren Sie in Übergangstechnologien, die den Betrieb und die Wartung von Mittelwegsystemen vereinfachen.

Wir haben uns mit einem weltweit führenden Anbieter von Software, Produkten und professionellen Dienstleistungen für Tierarztpraxen mit einem Umsatz von 4 Mrd. US-Dollar zusammengetan, um eine zukunftsweisende Microservice-basierte Plattform für das globale Verschreibungsmanagement (GPM) für die internationale Expansion zu entwickeln, die derzeit mehr als 10.000 Praxen in Nordamerika und etwa 100.000 Kunden in der globalen Lieferkette bedient. Es handelte sich um einen Greenfield-Ansatz zur Lösung der aktuellen Probleme mit den bestehenden monolithischen Systemen.

Die Umstellung auf das neue System braucht Zeit, und wir können nicht aufhören, wie gewohnt weiterzuarbeiten. Das ist es auch, was das neue System finanziert. Daher haben wir uns bewusst dafür entschieden, uns auf das neue System vorzubereiten und Pipelines für die Datenmigration in zwei Richtungen einzurichten. Mit „zwei Wegen“ meinen wir, dass die Daten vom neuen zum alten System und umgekehrt synchronisiert werden.

Das bedeutet im Wesentlichen, dass die Daten dupliziert und synchron gehalten werden, um den Schritt zum Übergang auf ein neues System zu vollziehen. Es sah also in etwa so aus:

Abbildung: „Zwei-Wege“-Datensynchronisation

Diese Pipeline wird irgendwann auslaufen, aber es ist die Mühe wert, das neue System mit dem alten System synchron zu halten und umgekehrt. Der Vorteil, den wir erhalten, ist eine Verschnaufpause in der Übergangsphase, in der das Unternehmen die anstehenden Aufgaben für die Umstellung auf ein neues System betrachtet, das Budget und die Zeitpläne anpasst und insgesamt das Leben ein wenig einfacher macht, weil die Dinge weiterlaufen, wenn auch mit höheren Kosten. Die gute Nachricht ist, dass das Geschäft immer noch Geld einbringt.

2. Aufbau der Orchestrator-Schicht.

Der nächste Schritt ist der Aufbau einer Orchestator-Schicht, die den Datenverkehr von den bestehenden Front-End-Anwendungen zu den neuen Back-End-Systemen leitet. Diese Schicht wird dafür sorgen, dass die Nutzer des Systems weiterhin einen nahtlosen Übergang haben werden. Im Hintergrund wurde das alte System ersetzt, ohne dass die Benutzer davon betroffen sind. Auch dieser Schritt kann mit verschiedenen Bereitstellungsstrategien wie Blue Green Deployment durchgeführt werden. Und da die Daten immer im Hintergrund synchronisiert werden, können Sie im Falle von Problemen mit dem neuen System zurückschalten.

Abbildung: Die Orchestrator-Schicht

Bei der Erstellung des API-Satzes in der Orchestator-Schicht sollten Sie darauf achten, dass die Architektur zukunftsorientiert ist. Die Orchestator-Schicht bleibt auch im neuen System erhalten und ist kein Wegwerfcode. Wenn dazu eine Wrapper-Schicht oder ein Adapter für das Legacy-Frontend benötigt wird, lassen Sie dies zu. Dies wird ein Wegwerfcode sein, der aber dennoch sein kurzes Leben in vollen Zügen genießen wird. Der Grund dafür ist, dass das Design für Ihre Orchestrierung sauber und makellos bleibt.

3. Die bittere Pille schlucken und auf ein neues System migrieren.

Es gibt keinen einfacheren Weg, als jetzt in den sauren Apfel zu beißen. Erstellen Sie die neue moderne Benutzeroberfläche mit der Technologie Ihrer Wahl und sorgen Sie dafür, dass die moderne Benutzeroberfläche die gleiche Sprache spricht wie der Orchestrator-Dienst. Schalten Sie das alte System schrittweise aus. Führen Sie einen Alphatest durch, wählen Sie dann eine Gruppe von Betanutzern für die Migration aus, und schließlich können alle Nutzer migriert werden. So haben Sie genügend Vorlauf für die endgültige Einführung.

Manchmal erfordert die Migration auf ein neues System mehr Planung und Aufwand als die Entwicklung von Green Field-Anwendungen. Ein solch großes Problem erfordert, dass wir es in kleinere Problemstellungen aufteilen und die kleineren Probleme nach und nach beheben. Dies kann so einfach sein wie die Migration von On-Premise zu Cloud und kann auch komplexe Geschäftsregeln beinhalten, die für die Transformation angewendet werden müssen.

Im Fall unseres Kunden haben wir beispielsweise einen benutzerdefinierten Microservice entwickelt, dessen einzige Aufgabe es war, Daten aus allen unterschiedlichen Quellen aufzunehmen und am endgültigen Zielort zu platzieren. Dieser Dienst wurde nur einmal verwendet, war aber entsprechend den Geschäftsregeln für die Transformation leicht zu manipulieren.

Abbildung: Die endgültige Inbetriebnahme der benutzerdefinierten Migration Engine

Fazit

Das monolithische Altsystem hat sein Leben gelebt, und die Abschaffung des gesamten Monolithen ist eine gewaltige Aufgabe. Es gibt Lösungen, die den Weg zur North Star-Architektur erleichtern. Es ist ratsam, frühzeitig in diese Lösungen zu investieren und Ihr Budget zu nutzen, um das Leben einfacher zu machen.

Diese Systemmuster für die Mitte des Weges sind dazu da, Ihre Reise zu vereinfachen, und wenn Sie sie nutzen, vermeiden Sie den Fauxpas, die monolithischen Systeme zu strangulieren. GlobalLogic’s Digital Advisory & Assessment kann Ihnen auf Ihrer Reise vom Monolithen zu einer digital transformierten Architektur helfen, den richtigen Weg zu wählen, die Schritte auf dem Weg zu vereinfachen und Ihr Endziel mit einer erfolgreichen, nachhaltigen Lösung zu erreichen, die Ihr Unternehmen voranbringt.