Legacy wird abgelöst

Sie haben also den grundlegenden Entschluss gefasst, ihr Legacy System zu erneuern. Haben Sie ebenfalls schon eine Strategie festgelegt, wie das passieren soll? Sollen Teile zielgerichtet upgegradet werden, um beispielsweise auf aktueller Hardware oder um in einem neuen Environment lauffähig zu werden? Oder geht es eher in die Richtung einer kompletten Ablöse mit neuen Technologien und moderner Architektur? Oder liegt die Wahrheit irgendwo dazwischen? Was auch immer ihr Ziel ist, und wenn es auch noch weit in der Zukunft liegt, auch der Ablöseprozess an sich muss gut durchdacht und vorbereitet werden.

Unabhängige Komplettablöse oder "Step by Step"-Migration?

Diese Entscheidung wird Ihnen manchmal abgenommen: Ist die neue Lösung mit dem abzulösenden System einfach nicht kompatibel, bleibt einem nur die unabhängige Komplettablöse. Das trifft oft bei (customisierten) Off-the-Shelf Lösungen zu. Die Chance, hier von einem OtS auf ein anderes schrittweise zu migrieren, ist gering. Die zumeist stark unterschiedlichen Lösungen eignen sich nicht für eine schrittweise Ablöse.

Falls jedoch eine Eigenentwicklung durch eine neue Eigenentwicklung abgelöst werden soll, stellt sich diese Frage sehr wohl. Hier hat man zumindest die theoretische Möglichkeit, den einen oder den anderen Weg zu gehen.

Folgende Faktoren können die Entscheidung beeinflussen:

• Sind die Technologien miteinander kompatibel bzw. kann die neue Umsetzung einfach in die alte integriert werden? Oder schränkt eine Integration die Zielarchitektur nur unnötig ein?
• Wie sehr muss das Legacy System angepasst werden, um eine Integration zu ermöglichen und sind die notwendigen Ressourcen und das notwendige Know-How dafür vorhanden? Können diese Anpassungen einfach getestet werden oder ist das Risiko eines Folgefehlers zu hoch?
• Ist die Integration der beiden Entwicklungen mit hohem zusätzlichem Aufwand verbunden? Gibt es dafür hinreichende Gründe, um den Mehraufwand trotzdem zu rechtfertigen?
• Ist die Integration für den Endbenutzer transparent oder entstehen dadurch nennenswerte Usability-Hürden?

Eine Komplettablöse im Vergleich zu einer "Step by Step"-Migration ist oft einfacher, weil "auf der grünen Wiese" entwickelt werden kann: Technologie, Architektur aber auch die Arbeitsweise und der komplette Entwicklungsprozess können komplett neu und zielgerichtet ausgewählt und umgesetzt werden. Oft nutzt man so ein Projekt auch bewusst als Spielwiese für gänzlich Neues und (zumindest im Unternehmen) bisher Unerprobtes, beispielsweise agile Prozesse oder eine neue Teststrategie. Aber alles mit Bedacht: Schraubt man an zu vielen Stellen gleichzeitig steigen allgemein die Risiken für das Projekt.
Ein weiterer Vorteil ist, dass das Legacy System bei einer unabhängigen neuen Lösung komplett unangetastet bleibt - oft zeichnet sich das Legacy System ja gerade dadurch aus, dass es am besten komplett unangetastet bleiben soll (Legacy Code als „code that developers are afraid to change“). Die Komplettablöse hat aber zumindest den Nachteil, dass Erfahrungen mit der neuen Lösung und greifbare Ergebnisse sehr lange (quasi bis zu Fertigstellung und Ablöse) auf sich warten lassen.

Bei der schrittweisen Ablöse werden Teile des Legacy Systems iterativ herausgelöst und durch eine Neuentwicklung ersetzt. Der Grundstein dafür ist mitunter aber arbeitsintensiv, denn das Legacy System ist üblicherweise nicht dafür ausgelegt, auseinandergenommen zu werden. Oft sind dafür zusätzliche Schnittstellen im Legacy System notwendig. Auch der Einsatz eines "Proxies" oder einer Middleware, die die alte und die neue Welt miteinander verbindet, ist nicht unüblich und oft notwendig.
Steht diese Architektur aber grundlegend, kann das Legacy System schrittweise abgelöst werden. Dafür eignet sich oft eine auf MicroServices basierende Lösung: das Legacy System wird in funktional zusammenhängende Cluster unterteilt, die jeweils durch ein MicroService abgebildet werden. Die einzelnen MicroServices können direkt, oder bei Bedarf über die neue Middleware, kommunizieren. Die neue Lösung ersetzt also schrittweise das Legacy System, bis alle (notwendigen) Funktionen übernommen wurden und das Legacy System deaktiviert werden kann.

Schrittweise Erweiterung des Legacy Systems durch
MicroServices und einem eigenem Service Broker

Welche Strategie ist jetzt die bessere? Die Antwort lauten natürlich: it depends! Eine allgemeingültige Aussage dafür gibt es nicht, beide Ansätze haben ihre Vor- und Nachteile, die gegeneinander abgewogen und bewertet werden müssen. Meiner Erfahrung nach ist jedoch eine schrittweise Migration, falls technisch und organisatorisch machbar, oft die bessere Lösung.

Parallelbetrieb oder "Big Bang"?

Egal ob das Legacy System schrittweise migriert oder durch eine neue, unabhängige Lösung ersetzt wird, stellt sich die Frage, wann denn die neue Lösung eingesetzt werden soll? Wartet man die Fertigstellung der neuen Lösung ab oder kann man, bzw. muss man sogar, schon vorher Teile sinnvoll verwenden? Welchen Mehraufwand bedeutet es, beide Lösungen parallel zu betreiben und ist das technisch überhaupt sinnvoll möglich?

Ein Parallelbetrieb verringert das Risiko der eigentlichen Ablöse, denn alle Beteiligten/Betroffenen (Endbenutzer, Entwickler, Tester, Operations, ...) bekommen so die Möglichkeit, frühzeitig und gezielt Erfahrungen mit dem neuen System (oder eben Teilen davon) zu sammeln. Ein Gegensteuern bei ungewollten Ergebnissen ist damit frühzeitig möglich.
Für einen Parallelbetrieb müssen aber die technischen Voraussetzungen stimmen, denn beide Welten müssen im Endeffekt während des Parallelbetriebs voll in das Unternehmen integriert sein. Im Best Case sind beide Systeme so miteinander verbunden, dass zumindest ein Teil der Arbeitsergebnisse in beiden Systemen jederzeit verfügbar ist und so der Endbenutzer die freie Wahl hat, welches System er verwenden möchte. Im Worst Case ist die Datenhaltung strikt getrennt und jeweils nur in einem der beiden Systeme verfügbar. Beide Varianten sind denkbar, wobei der Overhead einer strikt getrennten Datenhaltung meist nur zeitlich stark begrenzt und mit einer kleinen Nutzergruppe Sinn macht.

Parallelbetrieb der beiden unabhängigen Systemen (Legacy und Neu)
mit zyklischer Synchronisierung der Daten

Die Ablöse durch einen "Big Bang" ist zumindest eines: spannend. Jeder, der schon einmal bei so einem Event dabei war, weiß das. Üblicherweise wird das Legacy System zu einem gewissen Zeitpunkt abgeschaltet und alle Daten in das neue System migriert. Ein Rückstieg auf das Legacy System ist fast niemals geplant oder möglich, da sich der Aufwand dafür nicht rentiert. Diese in Summe wenigen Schritte dauern mitunter mehrere Tage, in denen weder das alte noch das neue System aktiv sind. Teilweise zahlt es sich sogar aus, für diese Downtime eigene Zwischenlösungen zu bauen, wenn der sonst verlorene Umsatz die Entwicklungskosten übersteigt. Ab da an ist nur noch das neue System aktiv, und alle Beteiligten atmen tief durch, wenn der Normalbetrieb wieder erreicht ist. Ein gut durchdachtes, sehr detailliertes und zumindest einmal erprobtes Umstiegsszenario ist dabei jedenfalls Pflicht und hilft in diesen angespannten Stunden oder Tagen immens!

Auch diesmal stellt sich die Frage, welches Szenario denn das bessere ist, und Sie ahnen es wohl bereits: it depends (again)! Der Parallelbetrieb ist initial aufwendiger, wenn er überhaupt möglich ist. Aber dann ist er dem "Big Bang" meiner Erfahrung nach vorzuziehen. Die Erfahrungen aus dem Parallelbetrieb und das nicht vorhandene "Umstiegswochenende" überwiegen hier. Aber auch Aspekte, die nicht technischer Natur sind, haben Einfluss auf die Entscheidung: Es kann sein, dass die neue Lösung so früh wie möglich platziert werden soll, auch wenn der Funktionsumfang noch weit hinter dem des Legacy Systems liegt und der Aufwand für den Parallelbetrieb enorm ist. Doch gerade, wenn es darum geht, dass ein Unternehmen auf dem Markt sich einen Vorteil beim Mitbewerb dadurch erhofft, wird diese Strategie gerne verfolgt.