Modernisierung einer Legacy Software-Architektur

Carsten Pelka

Der Begriff Legacy System gehört in der IT-Industrie vermutlich zum Grundwortschatz. Und das nicht nur bei Entwicklern und Architekten, sondern auch bei Teamleitern, Produktmanagern und bis hinein ins Management. Es ist daher auch nicht abwegig, dass es ein sehr unterschiedliches Verständnis des Wortes „Legacy“ gibt, das nicht eindeutig definiert, dafür aber leider mitunter negativ behaftet ist. Dabei ist bei einer längeren Laufzeit allerdings davon auszugehen, dass ein solches System nach wie vor einen wichtigen Beitrag zur Wertschöpfungskette des Unternehmens liefert. „Legacy System“ bezeichnet allerdings nichts anderes als ein historisch gewachsenes IT-System und sollte nicht als „Altlast“ verstanden werden (siehe Wikipedia Altsystem). Es besteht darüber hinaus aus deutlich mehr als nur dem „Legacy Code“, der eher als das Ergebnis der Umsetzung von funktionalen Anforderungen entlang der Richtlinien durch die Software-Architektur angesehen werden kann. Entsprechend berücksichtigt eine solche Legacy Modernisierung zwei Dimensionen: die Anpassung an neue Rahmenbedingungen (regulatorische Anforderungen, Fachlichkeit, Veränderungen im Markt etc.) und die Modernisierung der Technik, dem Schwerpunkt dieses Artikels.

Wie erkennt man ein Legacy System?

Bevor der Entschluss fällt, ein Legacy System zu modernisieren, muss es als solches zunächst einmal erkannt werden. Es gibt zwar keine einfachen Metriken, allerdings verschiedene Indikatoren, die Aufschluss darüber geben, ob ein System als Altsystem verstanden werden kann und einer entsprechenden Modernisierung bedarf. Auslöser einer solchen Untersuchung kommen häufig aus beiden Richtungen: die Entwickler schlagen aufgrund von Problemen in der Umsetzung immer häufiger Alarm und/oder die Kennzahlen (Key Performance Indicators, kurz KPIs, wie etwa Time to Market) des Managements sinken kontinuierlich. Durch regelmäßige Architektur-Reviews lassen sich aufkommende Probleme frühzeitig erkennen.

Zur Klärung des Zustands eines Systems dient dabei folgende Kardinalfrage:

Aufgrund der individuellen Konstellation eines jeden Softwareprojekts ist die Beantwortung dieser Frage nicht trivial. Vielmehr ist es der Beginn eines möglichen Modernisierungs-Prozesses. In dieser Evaluations-Phase wird das System zunächst als Blackbox betrachtet. Die Blackbox-Sicht fokussiert auf die äußeren Aspekte. Der Reihe nach werden die folgenden Fragen geklärt:

1. Wer hat Interesse an dem System?
2. Was ist das System?
3. Welche Qualitätsanforderungen muss das System erfüllen?

Der erste Schritt ist die Stakeholder-Analyse, in der alle relevanten Rollen und Personen identifiziert werden, die entweder Einfluss auf das System und seine Architektur nehmen oder auf die das System Auswirkungen hat. Dies sind vor allem Personen aus den Fachbereichen, aber auch Technik, Management und Kunden können diesem Kreis angehören.

Mit den Stakeholdern gilt es, das System als Ganzes im Geschäftskontext abzugrenzen, um ein klares Verständnis der Verantwortlichkeiten des Systems zu erhalten. Die Frage „Was ist das System?“ zielt also auf die Geschäftssicht, nicht auf die technische Sicht. Jedes System lässt sich durch seinen Zweck, also den geschäftlichen Mehrwert, beschreiben. Ergänzt werden auf diesem hohen Level weitere charakteristische Merkmale wie etwa Datenflüsse, Systeminteraktionen und Schnittstellen, soweit es für das allgemeine Verständnisbild des Systems erforderlich ist. Eine solch detaillierte Kontext-Abgrenzung dient der Beantwortung dieser Kernfrage und wird beispielhaft in Abbildung 1 dargestellt. Im gleichen Zuge sollten die technischen und organisatorischen Randbedingungen, die für dieses System gelten, erfasst werden.

Gemeinsam mit den Stakeholdern werden im letzten Schritt die Anforderungen an die Qualität des Systems ausgearbeitet und priorisiert. Zum besseren Verständnis von Softwarequalität sei an dieser Stelle auf die entsprechende ISO/IEC-Norm 25010 (siehe ISO/EIC 25010:2023, Systems and software engineering - Product quality model) oder das etwas handlichere und öffentlich frei verfügbare arc42 Qualitätsmodell verwiesen, sowie auf die Ausführungen in Effektive Softwarearchitekturen von Gernot Starke [1].

Abschließend wird das bestehende System anhand der kritischen und hoch-prioren Qualitätsanforderungen gemessen und bewertet. In diesem Schritt kann es schon notwendig werden, die technische Umsetzung etwas detaillierter zu betrachten und ein Review durchzuführen. Es gibt aber auch kritische Qualitätsmerkmale, die zu einer frühen finalen Bewertung führen können. Ein praktisches Beispiel aus der Realität soll dies verdeutlichen: in der Finanz- und Versicherungsbranche werden auch heute noch in COBOL entwickelte Lösungen betrieben. Die Anzahl der Experten in diesem Bereich hat in den letzten Jahren kontinuierlich abgenommen aufgrund des altersbedingten Ausscheidens aus dem Beruf und wird auch weiterhin sinken, denn der Entwickler-Nachwuchs wird schon seit Jahrzehnten nicht mehr auf diese Art der Software trainiert. Es ist also abzusehen, dass der Markt mittelfristig nicht mehr ausreichend Personal bereitstellen wird, damit alle Unternehmen ihre Anwendungen auch weiterhin zuverlässig warten oder sogar erweitern können. Allein die Bewertung der kritischen Qualitätsmerkmale in Bezug auf Änderbarkeit und Wartbarkeit liefert rote Warnsignale: ein solches System kann mutmaßlich relativ schnell als Legacy System verstanden werden.

Es muss aber nicht immer dieses Extrembeispiel sein, auch die Ankündigung oder bereits erfolgte Erreichung des End-of-Life (EoL) einer grundlegenden Bibliothek oder eines Software-Produkts können kritische Indikatoren sein.

Sollte diese Analyse ergeben, dass die Qualität der Software nicht mehr ausreichend ist und die Unternehmensziele gefährden kann, so bleibt im Prinzip nur die Modernisierung, welche sich über ein breites Spektrum von Zukauf über Anpassung bis hin zu Neuntwicklung erstreckt. Auch wenn die Optionen sehr unterschiedlich wirken, der Prozess für eine erfolgreiche Modernisierung setzt auf die gleichen Eckpfeiler (siehe Abbildung 2). Das Ziel des weiteren Vorgehens ist es dann, die IST- und SOLL-Architekturen zu erheben, um einen umsetzungsfähigen Migrationsplan zu entwerfen. Ob es sich um eine Anpassung oder eine Neuentwicklung handelt, ist häufig im Vorfeld noch nicht abzuschätzen. Diese Fragen sind durch die Erarbeitung des Migrationsplans zu klären und mit den Stakeholdern zu entscheiden.

Für den Fall, dass es sich beim Bestandssystem und/oder dem neuen System um nicht anpassbare Kaufsysteme handelt, reduzieren sich die zu betrachtenden Fragen im Zuge des Migrationsplans vor allem auf den Betrieb und die Daten.

Bestehende Architektur verstehen oder erheben

In der ersten Phase gilt es, die Architektur des existierenden Systems zu verstehen. Als IST-Architektur beschreibt sie das aktuelle System und somit den Ausgangspunkt für die Erstellung eines Migrationsplans für eine erfolgreiche Modernisierung. Was aber, wenn keine Architektur-Dokumentation existiert oder diese selbst stark veraltet ist? In diesem Fall muss sie zunächst durch ein Re-Engineering erhoben werden.

Um aus einem bestehenden System die Architektur belastbar abzuleiten, gilt es, die gleichen Fragestellungen zu beantworten wie im Falle einer „vorwärts“ gerichtet entstandenen Architektur. Eine eventuell vorhandene, veraltete Architektur-Dokumentation kann hier immer noch als Grundlage dienen, um die Lücke zum aktuellen Zustand zu schließen. In vielen Fällen liegt aber eine solche Dokumentation nicht vor und es gilt, die wichtigen Fragestellungen von Grund auf zu beantworten. Dazu ist es notwendig, dass der oder die Softwarearchitekt(en) in diesem Prozess einen tieferen Blick auf den Aufbau und die Konzepte des Systems werfen. Idealerweise stehen einem System-fremden Architekten dabei mit dem System erfahrene Experten aus den Fachbereichen und auch Entwickler zur Seite. Als minimale Bestandteile lassen sich drei Bereiche definieren:

1. Aufbau des Systems & Datenmodelle
2. Konzepte der Implementierung
3. Auslieferung & Betrieb

Bei allen Analysen können und werden sich erfahrungsgemäß weitere Pfade öffnen. Es ist daher wichtig, die Struktur und das Ziel des Re-Engineerings nicht außer Acht zu lassen, denn sonst steigt die Gefahr in ein Rabbit Hole hinabzusteigen. Im Kontext des Re-Engineerings bedeutet dies, bei der Analyse konstant den Bezug zu den definierten Qualitätszielen und Rahmenbedingungen (wie Budget und Zeit) beizubehalten und diesbezügliche Stärken und Schwächen der aktuellen Architektur festzuhalten.

Entwurf der Zielarchitektur

Auch wenn die Erhebung der Zielarchitektur zum täglichen Brot- und Butter-Geschäft von Softwarearchitekten gehört, sollte im Kontext einer Modernisierung darauf geachtet werden, die Ergebnisse aus der vorangegangenen Phase nicht als Grundlage in diese Phase hineinzumischen und durch diese zu begründen. Der Entwurf der Zielarchitektur verläuft auf Basis der definierten Qualitätsanforderungen und den Randbedingungen.

Neue Architekturen müssen sowohl die fachlichen als auch die technischen Qualitätsziele tragen. Der Entwurf einer zeitgemäßen Architektur sollte sich an modernen Methoden orientieren, zum Beispiel dem Ansatz des Domain Driven Designs (siehe Warum Domain Driven Design von Eberhard Wolff), in dem die unterschiedlichen Kontexte erfasst und so gebündelt werden können, dass die Modularisierung entlang der fachlichen Welt geschieht. Dies führt in der Regel auch zu einer hohen Akzeptanz in den Fachbereichen und zu einer Entlastung der Entwicklung.

Sind mehrere Entwicklungs-Teams mit verschiedenen Modulen (oder sogenannten Domänen) vertraut, spricht man an dieser Stelle von der Makro-Architektur. Sie dient der Koordination zwischen den Teams und beinhaltet die übergreifenden Aspekte, darunter beispielsweise die Authentifikation und Autorisierung, Kommunikationspattern, Datenbesitz und Datensichten, Sicherheit, Betriebsplattform, Deployment-Pipelines etc. Ein weiterer Bestandteil ist die Eingrenzung des Entscheidungsspielraums für die Teams und damit die Mikro-Architektur der einzelnen Systeme.

Es empfiehlt sich, vor allem in der Makro-Architektur möglichst früh alle erkennbaren Unbekannten zu eliminieren und den Entscheidungsspielraum für Mikro-Architekturen bewusst eng zu halten. Während in so mancher „Greenfield“-Architektur häufig noch einige Themen erst während der Umsetzung entschieden werden können, bedarf es im Hinblick auf einen aussagekräftigen Migrationsplan eine sehr klar definierte Architektur, insbesondere im Hinblick auf die Zeitplanung und die Koordination zwischen den Teams.

Entwurf des Migrationsplans

Erst in der abschließenden Phase zur Erstellung des Migrationsplans werden IST- und SOLL-Architekturen miteinander verglichen und ihre Unterschiede festgestellt. Der Migrationsplan dient als Roadmap, um die Zielarchitektur zu erreichen. Er beschreibt die einzelnen Phasen der Umsetzung und umfasst die für einen möglichst reibungslosen Ablauf der Migration notwendigen Schlüsselkomponenten. Dazu zählen:

1. Zeitplanung: Definition der Phasen und Zeiträume, in denen der Migrationsplan stufenweise umgesetzt wird; kürzere und dafür mehr Phasen anstelle von wenigen bevorzugen, da aufkommende Probleme so sehr früh zu erkennen sind
2. Team-Planung: die Anforderungen an das Team sowie die Definition der Rollen über Aufgaben und Verantwortlichkeiten; bei einem verteilten System (Microservices, Self Contained Systems) gilt dies analog für alle Teams
3. Technische Ressourcenplanung: eine Liste der benötigten Werkzeuge und Infrastruktur für Entwicklung, Build/Deployment und Laufzeit-Umgebung. Dazu zählt auch die technische Kommunikation zwischen den Systemen (synchron vs. asynchron, pull vs. push, Events, Feeds, REST etc.)
4. Datenmigration: beschreibt die Verteilung und den Besitz von Stammdaten und Bewegungsdaten (bzw. Datensichten) sowie die Transformation der Bestandsdaten und Datenströme in das neue Modell. Idealerweise ist jegliche Datenmigration dabei nicht-destruktiv ausgelegt.
5. Tests & Monitoring: um die Funktionalität, Leistung und Sicherheit des migrierten Systems zu überprüfen und dauerhaft zu gewährleisten.
6. Schulung & Support: Schulungen für Stakeholder, insbesondere der Nutzer des neuen Systems sowie Hilfestellung in Fehlerfällen für Nutzer und Betrieb
7. Notfallplanung: insbesondere kritische (Teil-)Migrationen müssen im Vorfeld erkannt werden. Es muss sichergestellt werden, dass jede Migration im Falle eines Fehlschlags durch einen Wiederherstellungsplan zurückgerollt werden kann
8. Risiko-Analyse & Management: potenzielle Risiken, die den Migrationsprozess beeinträchtigen könnten, werden identifiziert. Strategien zur Minimierung oder Beseitigung dieser Risiken werden erarbeitet und verifiziert.

Anpassung oder Neubau?

Je nach Grad der Divergenz stehen ein oder zwei Szenarien zur Entscheidung: Anpassung oder Neubau. Kann ein Szenario bereits ausgeschlossen werden, ist dies mit einer Begründung kenntlich zu machen und mit den Stakeholdern abzustimmen. Pauschal ist keine Lösung einer anderen überlegen, sicher ist aber: je weiter entfernt das existierende System von aktueller Technik ist, desto aufwändiger wird ein möglicher Umbau. In beiden Szenarien sollte auch der Zukauf von Standard-Software oder einzelnen Diensten geprüft werden, wobei die Grenzen durch die Architektur vorgegeben werden, und nicht andersherum.

Der Umbau eines existierenden Systems wirkt generell dennoch etwas einfacher: die Kernfunktionalitäten sind bereits implementiert und das System kann stückweise verändert werden. Auf zwei Risikofaktoren sei explizit verwiesen: zum einen ist die Technologie gesetzt und die Implementierung nutzt eventuell Bibliotheken oder Versionen, die dringend ersetzt werden müssen. Zum anderen ist ein solcher Umbau häufig mit größeren Refactorings verbunden, die mitunter zu ungewolltem Verhalten führen können. Das Risiko dieser beiden Faktoren lässt sich allerdings durch eine sehr gute Testabdeckung weitestgehend reduzieren. Falls diese (noch) nicht existiert, sollte also vor dem Beginn des Refactorings daran gearbeitet werden. Ein besonderer Fall des Umbaus ist die Zerschlagung eines Monolithen, bei der also das existierende System in einzelne Services zerlegt wird. Einen Bericht zu den Herausforderungen eines solchen Vorhabens liefert [2].

Die Neuentwicklung eines Systems bietet dagegen traditionell einige Vorteile wie etwa die relativ freie Auswahl an neuen Technologien (Programmiersprachen, Frameworks, Datenbanken, Laufzeit-Umgebungen) und damit verbunden die Ablösung eben jener alten Technologien, die unter Umständen nicht mehr gewartet werden oder lizenzpflichtig sind und zu denen es mittlerweile kostenfreie oder auch geeignetere Alternativen gibt. Ein besonderes Augenmerk gilt beim Neubau-Szenario der Überlegung in welchen Phasen Daten migriert (und dabei transformiert) werden. Vor allem dann, wenn die Daten künftig in einer anderen Art verteilt werden sollen, etwa wenn ein kanonisches Datenmodell aufgeteilt wird. Dazu müssen die entsprechenden Funktionalitäten evtl. über Service-Grenzen hinweg – und in Abstimmung mit dem Altsystem – umgesetzt sein.

Die erfolgreiche Umsetzung

Ein belastbarer und nachvollziehbar ausgearbeiteter Migrationsplan kann üblicherweise auch erfolgreich umgesetzt werden. In kurzen Zyklen werden die Etappenziele überprüft, so dass Probleme frühzeitig erkannt werden und gegengesteuert werden kann.

Die Arbeit des oder der verantwortlichen Softwarearchitekten endet jedoch nicht mit Beginn der Umsetzung oder einem bestimmten Meilenstein, denn sonst würde auch diese Architektur schnell wieder zu einem Altsystem führen. Es gilt, neue Rahmenbedingungen, Qualitätsanforderungen und auch technischen Fortschritt frühzeitig zu erkennen und die möglichen Änderungen an der Softwarearchitektur transparent zu kommunizieren. Durch diese kontinuierliche Modernisierung der Softwarearchitektur ist es möglich, den Alterungsprozess für eine sehr lange Zeit zu verlangsamen. Zumindest so lange, bis es kritische Faktoren gibt.