Legacy-Modernisierung bezeichnet den Prozess, alte Softwaresysteme wie Cobol-Mainframes oder frühe Java-Monolithen in moderne Architekturen zu überführen. Der größte Engpass dabei ist fehlendes Fachwissen über die Altsysteme. Retrieval Augmented Generation (RAG) löst das: Der Altcode wird als Knowledge Graph aufbereitet und per KI direkt abfragbar gemacht.
Das Wichtigste in Kürze
- Fehlende Subject Matter Experts, nicht mangelnde Technik, waren bei einer realen Legacy-Modernisierung der Hauptgrund dafür, dass das Projekt drei Quartale hinter dem Zeitplan lag.
- Retrieval Augmented Generation löst das SME-Engpass-Problem, weil der Legacy-Code in einen Knowledge Graph überführt wird und Entwickler per Chat gezielt Fragen an die Codebasis stellen können, ohne das Modell neu trainieren zu müssen.
- Microservices, die nach Nomen benannt sind (Customer Service, Product Service), erzeugen stärkere Kopplung als Verb-basierte Services, weil Business-Prozesse dann typischerweise alle Services gleichzeitig berühren.
- Zu viele Tokens im Prompt verschlechtern die Antwortqualität, weil Informationen in der Mitte des Kontextfensters vom Modell schwächer gewichtet werden als Inhalte am Anfang und Ende.
Wann gilt Software als Legacy?
Legacy-Software lässt sich nicht über ein festes Alter definieren, sondern eher über ihre Technologie und darüber, wie schwer sie sich noch verändern lässt. Mainframe-Systeme in Cobol zählen klar dazu. Aber auch Software, die Anfang des Jahrtausends in frühen Java- oder .NET-Versionen entstand, fällt heute in diese Kategorie.
Erik Doernenburg, der bei der Beratungsfirma ThoughtWorks arbeitet, sieht in der Versicherungs- und Bankenbranche besonders viele dieser Systeme. Viel von dem, was Kunden modernisieren wollen, existiert längst und soll verändert, verbessert oder in die Public Cloud überführt werden.
Zwei Gründe halten Teams davon ab, an solche Systeme heranzugehen. Der erste sind fehlende Tests. Niemand traut sich Änderungen zu, weil niemand mehr genau versteht, wie das System funktioniert. Die Leute, die heute Anpassungen machen, sind selten die, die den Code ursprünglich geschrieben haben. Das Wissen wurde über Jahre von Hand zu Hand weitergegeben, oft auch von Dienstleister zu Dienstleister.
Der zweite Grund ist das fehlende Verständnis für die Fachlichkeit. Gerade im Versicherungsbereich entstehen durch Übernahmen und Fusionen Systeme, bei denen niemand mehr weiß, wie die Policies aussahen, die vor 15 Jahren verkauft wurden. Erschwerend kommt hinzu, dass technische Aspekte und Geschäftslogik im Code oft vermischt sind. Wer die Fachlogik verstehen will, stolpert ständig über Infrastruktur-Code für Datenbank oder Oberfläche.
Subject Matter Experts sind der eigentliche Engpass
Bei großen Modernisierungsprojekten ist nicht die Technik das Hauptproblem, sondern der Zugang zu Menschen, die das Altsystem erklären können. Eine Analyse bei einem großen deutschen Kunden zeigte das deutlich. Das Projekt lag drei Quartale hinter dem Zeitplan, die Kosten waren hoch, und die Ursache war das Fehlen von Subject Matter Experts.
Diese Experten erklären den Teams, die neue Software schreiben, wie die alte funktioniert. Genau dort entsteht der Bottleneck. Das Problem lässt sich nicht durch Einstellungen oder interne Umverteilung lösen. Die Leute sind oft gar nicht mehr im Unternehmen oder so rar, dass man in der verfügbaren Zeit keinen Zugriff auf sie bekommt.
Subject Matter Experts, Leute, die den Teams, die neue Software schreiben, erklären können, wie die alte Software funktioniert: das war der Bottleneck.
Erik Doernenburg
Warum auch moderne Microservices wieder Legacy werden
Die Idee hinter Microservices war, Legacy in der heutigen Form überflüssig zu machen. Kleine, deployable Units sollten sich nach fünf oder zehn Jahren mit modernerer Technologie ersetzen lassen, ohne das ganze System anzufassen. Solche Brandmauern erlauben es, Teile neu zu kombinieren und einzeln wegzuwerfen.
Bei vielen Unternehmen funktioniert das. Gut geschnittene Services fristen ihr Nischendasein am Rand, laufen stabil und blockieren keine Änderungen an Code, der sich stärker wandelt. Andere Unternehmen landen beim “distributed monolith”, bei dem die Kopplung zwischen den Services so hoch ist, dass eine Änderung in einem Service drei weitere mitzieht. Solche Systeme werden über kurz oder lang wieder zu Legacy.
Erik nennt eine einfache Faustregel, an der sich das frühzeitig erkennen lässt. Sie betrifft die Namen der Services.
| Namensgebung | Wahrscheinliche Folge |
|---|---|
| Service trägt ein Nomen (Customer Service, Product Service) | Höhere Wahrscheinlichkeit für starke Kopplung, weil Geschäftsprozesse über mehrere Services laufen |
| Service ist an ein Verb angelehnt (z. B. Order Capture) | Höhere Wahrscheinlichkeit für isolierte Services, die einen kompletten Geschäftsprozess abbilden |
Wenn du einen Geschäftsprozess ändern willst und dafür quer durch Customer-, Product- und weitere Services greifen musst, ist die Kopplung zu hoch. Services, die einen vollständigen Prozess kapseln, lassen sich später ersetzen, ohne andere zu stören. Die ursprüngliche Absicht hinter Microservices war nie Entity-Relationship-Modeling, sondern Geschäftsfunktionalität in möglichst autonome Stücke zu zerlegen.
In Scheiben modernisieren statt in einem großen Wurf
Die wichtigste Strategie bei einer Modernisierung ist, sie nicht in einem großen Schritt zu machen, sondern scheibenweise. Eine Mainframe-Modernisierung, die über zwei oder drei Jahre läuft, zwischendurch keine Ergebnisse liefert und am Tag X alles auf einmal umschaltet, ist ein Hochrisikospiel, das kaum noch jemand eingeht.
Stattdessen suchen die Teams einzelne Funktionalitäten heraus, die sich isoliert betrachten und übertragen lassen. Dafür braucht es genug Leute im Unternehmen, die die fachliche Funktionalität kennen.
Je länger ein Team in ähnlicher Konstellation zusammenarbeitet, desto besser wird seine Vorhersagekraft. Es hält die Scheibengröße konstanter und kann abschätzen, wie viel noch übrig ist. Wenn eine Scheibe etwa drei bis vier Wochen dauert und klar ist, wie viele noch kommen, lässt sich planen, auch wenn eine mal länger braucht. Das schafft Vertrauen bei den Stakeholdern auf der Geschäftsseite.
Dieser Ansatz vermeidet das sogenannte Melonenreporting. Außen grün, innen rot: Nach oben wird kommuniziert, dass alles läuft, bis drei Wochen vor Ende eines Zweijahresprogramms plötzlich noch ein halbes Jahr fehlt.
Tests als Sicherheitsnetz für den Umbau
Ohne Tests lässt sich Legacy nicht sicher modernisieren. Je mehr Test-Coverage ein Altsystem mitbringt, desto besser. In manchen Fällen schreiben die Teams zuerst Tests, um überhaupt eine Absicherung zu haben.
Für Modernisierungen sind End-to-End-Tests wertvoll, mit denen sich nach jeder Änderung prüfen lässt, ob das System noch funktioniert. Eine weitere Strategie ist, altes und neues System eine Weile parallel laufen zu lassen, durchaus drei bis sechs Monate. So zeigt sich, ob das neue System bei allen Eingaben aus dem täglichen Betrieb die gleichen Ausgaben liefert.
Dabei lohnt der Blick auf Monatsende und Jahresabschluss. Erik erinnert sich an einen Kunden aus dem Bankenumfeld, bei dem aufgeräumt und gelöscht wurde. Am Monatsende gab es Ärger, weil ein Prozess Messages verschickte, von denen niemand mehr wusste, woher sie kamen, die aber für die Gegenseite wichtig waren.
Für den neuen Code gilt dieselbe Disziplin. Wer am Anfang schnell vorankommt und technische Schulden anhäuft, verliert später an Geschwindigkeit. Die Teams setzen auf Test-Driven-Development, nutzen Unit-Tests, um den Code zu schreiben, und ergänzen End-to-End-Journey-Tests für den Durchlauf von Anfang bis Ende. Edge Cases gehören in die feingranularen Tests, dazwischen sorgen Integrationstests aus Performancegründen für die Mitte. Das ist die klassische Testpyramide.
Wie LLMs beim Verstehen von Altcode helfen
Large Language Models bringen den größten Nutzen nicht beim Schreiben von neuem Code, sondern beim Verstehen von altem. Beim Forward Engineering, also dem Code-Generieren, halten sich die Produktivitätsgewinne in überschaubarem Rahmen. Eine Microsoft-Studie nannte 55 Prozent höhere Geschwindigkeit mit Copilot, doch dabei ging es um den reinen Akt des Programmierens und um einen Webserver in JavaScript, für den es im Internet hunderte bis tausende Beispiele gibt.
Bei spezialisierter Fachlogik kippt das Bild. Für Geschäftsprozesse einer Versicherung existiert deutlich weniger Quellcode im Internet, also auch weniger in den Modellen. Der Produktivitätsgewinn fällt entsprechend kleiner aus. Trotzdem will kaum ein Entwickler, der so ein Tool genutzt hat, es wieder hergeben, und gemessen an den Personalkosten sind die Lizenzkosten nahezu irrelevant.
Der eigentliche Hebel für Legacy liegt woanders. Erik sieht ihn in einem Muster, das sich Retrieval Augmented Generation nennt.
Retrieval Augmented Generation: Wissen aus dem Altsystem ziehen
Retrieval Augmented Generation löst das Halluzinationsproblem, indem das Modell die Antwort nicht aus sich selbst generieren muss, sondern in mitgeliefertem Text finden soll. Statt zu fragen “Wo in der Codebase passiert X?” lautet der Prompt sinngemäß: Beantworte die Frage anhand des folgenden Textes. Und in diesem Text stehen die Dokumente aus dem eigenen Unternehmen.
Technisch funktioniert das über Embeddings. Aus einem Textdokument berechnet das Modell einen Zahlenvektor, der inhaltlich ähnliche Dokumente in eine ähnliche Richtung zeigen lässt. Diese Vektoren landen in einer Vektordatenbank. Vor jeder Anfrage berechnet das System den Vektor des Nutzer-Prompts, sucht die passenden Dokumente und gibt sie zusätzlich zum Prompt mit. Das ist die Augmentation. Eigene Modelle muss niemand trainieren, die Unternehmensdokumente müssen nicht im Modell stecken.
Für Legacy-Code haben die Teams daraus ein internes Toolkit gebaut, kein fertiges Produkt, sondern Skripte, eine Anleitung und ein Chat-Interface. Es nutzt einen Knowledge Graph, in den Quellcode, vorhandene Dokumentation und die Ausgaben klassischer Reverse-Engineering-Tools wie Dependency-Analysen einfließen.
Das Toolkit arbeitet in zwei Modi:
- Briefing-Dokumente generieren. Auf eine Aufforderung wie “Beschreibe die Fähigkeiten eines Admin-Users” entstehen wenige Seiten, die erklären, wie sich ein Admin-User im Code von anderen unterscheidet. Bei mindestens einem Kunden haben Subject Matter Experts diese Dokumente stichprobenartig geprüft und keine groben Fehler gefunden.
- Dialog im Chat. So wie ein Entwickler einen menschlichen Experten fragen würde, stellt er die Frage an das Tool. Aus dem Prompt findet das System passende Knoten im Knowledge Graph und läuft an den Kanten entlang, etwa zu Funktionen, die andere Funktionen aufrufen. So sammelt es gezielt das Wissen ein, das in den Prompt soll.
Kleine, präzise Prompts schlagen den großen Kontext
Mehr Kontext ist nicht automatisch besser. Unstrukturiert so viel wie möglich mitzugeben, ist nicht der beste Ansatz. Oft bringt es mehr, weniger, aber geschickter ausgewählte Information in die Augmentation zu packen.
Dahinter steht das “Lost in the Middle”-Problem. Gibt man sehr viele Tokens mit, werden Informationen am Anfang und am Ende offenbar stärker bewertet als die in der Mitte. Manche gehen deshalb dazu über, den Prompt mit einem kleineren Modell zu komprimieren.
Bei Quellcode gibt es einen eleganteren Weg. Statt mit dem Hammer zu komprimieren, lässt sich vorhandenes Reverse-Engineering-Wissen über Dependencies nutzen, um den Prompt gezielt anzureichern. Eine besonders aussagekräftige Information stammt aus der Versionshistorie: welche Dateien werden oft zusammen eingecheckt. Wenn drei Klassen immer gemeinsam committet werden, gehören sie inhaltlich zusammen, oft deutlicher als jede statische Call-Graph-Analyse zeigt. Solche Signale verbessern die Prompt-Augmentation erheblich, weil kleine, knackige Prompts genau das Wissen enthalten, das die Antwort braucht.
Auch die Kosten sprechen für diesen Ansatz. Große Input-Context-Windows, bei Google teils eine halbe Million Tokens, kosten sofort Geld, sobald man sie häufig nutzt. Gemessen an Personalkosten relativiert sich das zwar, doch ein präziser Prompt ist meist die bessere Wahl.
