Agentisches Reverse Engineering: Legacy als Wissensarchiv

In vielen Großorganisationen verabschiedet sich in diesen Jahren die Generation in den Ruhestand, die die heutigen Kernsysteme gebaut hat. Ihr Wissen steht in keinem Dokument, es steckt im Custom Code: in Eigenentwicklungen, Erweiterungen, Schnittstellen und Batchketten, die über Jahrzehnte festgehalten haben, wie das Unternehmen tatsächlich arbeitet. Mit diesem Beitrag eröffnen wir eine Serie zum agentischen Reverse Engineering und zeigen, warum Legacy-Systeme als Wissensarchiv zu behandeln sind, wie KI-Agenten dieses Archiv lesbar machen und was eine Organisation damit gewinnt.

Zwei Systeme, eines davon dokumentiert

Jede große Anwendungslandschaft besteht aus zwei Systemen. Das erste ist der Standard: die ERP-Software, die Datenbank, das Betriebssystem, dokumentiert und gewartet vom Hersteller. Das zweite ist das, was die Organisation über zwanzig oder dreißig Jahre darauf gebaut hat: eigene Programme und Reports, Erweiterungen und Modifikationen, User Exits, Schnittstellen zu Werken, Partnern und Altanwendungen, nächtliche Batchketten, die die Bücher schließen und die Ware bewegen. In großen Industriekonzernen umfasst dieser zweite Teil nicht selten zehntausende Objekte je SAP-System (Erfahrungswerte aus Sysparency-Analysen großer SAP-Landschaften). Er trägt die Differenzierung des Unternehmens, und er ist der Teil, für den es keine Dokumentation gibt.

Genauer: Es gibt sie, aber sie ist veraltet oder sie lebt in Köpfen. Die Fachkonzepte beschreiben, was einmal gebaut werden sollte, nicht, was heute produktiv läuft. Dazwischen liegen hunderte Change Requests, Sonderfälle und Workarounds, die nur die Menschen kennen, die das System seit Jahren betreuen. Wer in den frühen Neunzigerjahren als Entwicklerin oder Entwickler begonnen hat, nähert sich in diesen Jahren dem Pensionsalter. Mit jeder Verabschiedung verliert die Organisation nicht eine Arbeitskraft, sondern den Zugang zu einem Teil ihres Archivs.

Die Folgen kennt jede Transformationsverantwortliche und jeder Transformationsverantwortliche: Ablöseprojekte werden auf Basis von Schätzungen statt Fakten dimensioniert, Änderungsfenster werden gegen unbekannte Nebenwirkungen abgesichert, Prüferinnen und Prüfer halten die fehlende Dokumentation als Feststellung fest, und die S/4HANA-Transformation bleibt in der Analysephase stecken. Die Verordnung (EU) 2022/2554 (DORA), seit Januar 2025 anzuwenden, verlangt von Finanzunternehmen zudem die Identifikation und Dokumentation aller IKT-gestützten Geschäftsfunktionen. Das Wissen ist vorhanden. Der Zugang dazu ist verloren gegangen.

Legacy-Code ist kein Ballast, sondern das vollständigste Archiv darüber, wie ein Unternehmen tatsächlich arbeitet.

Warum Interviews und Workshops das Archiv nicht öffnen

Der klassische Weg, dieses Wissen zu heben, sind Interviews mit den verbliebenen Expertinnen und Experten, Workshops mit den Fachbereichen und die manuelle Durchsicht des Quellcodes. Alle drei Wege haben dieselbe Schwäche: Sie skalieren nicht mit der Größe des Systems. Unsere Praxis zeigt, dass mit manueller Dokumentation selbst nach fünf Jahren nur ein Bruchteil eines großen Bestandssystems beschrieben ist. In einem anonymisierten Fall aus unserer Beratungspraxis, dem Kernsystem einer Bank, wurde allein die Analyse und Dokumentation des tatsächlichen Systemverhaltens mit rund drei Jahren für ein komplettes Entwicklungsteam kalkuliert, annähernd ein Drittel des gesamten Ablösebudgets.

Hinzu kommt ein strukturelles Problem. Die Pensionierten kennen das Warum: weshalb eine Regel 2009 eingeführt wurde, welche Betriebsvereinbarung hinter einer Sonderbehandlung steht, warum ein Batch um zwei Uhr nachts und nicht um vier läuft. Der Code kennt jeden Pfad, aber nicht das Warum. Interviews liefern das Warum ohne Vollständigkeit, das Code-Lesen liefert Vollständigkeit ohne das Warum, und beides ist am Tag der Fertigstellung bereits veraltet, weil das System weiterläuft. Ein Reverse Engineering, das dieses Archiv wirklich öffnet, muss vollständig, belegt und wiederholbar sein, und es muss das Warum aus den Köpfen mit dem Wie aus dem Code verbinden.

Was „agentisch“ am Reverse Engineering verändert

Innerhalb weniger Jahre haben sich KI-Systeme in der Softwareentwicklung von der Autovervollständigung zu Agenten entwickelt, die mehrstufige Aufgaben selbstständig planen und abschließen. Für das Reverse Engineering bedeutet das: Agenten lesen jeden Programmbaustein eines Systems, nicht eine Stichprobe; sie bedienen eine Anwendung Maske für Maske wie eine Anwenderin oder ein Anwender; und sie erklären, was sie vorfinden, in fachlicher und in technischer Sprache. Was früher ein Großprojekt war, wird zu einem wiederholbaren Analyselauf.

Ein Prinzip ist dabei entscheidend, und wir halten es in jedem Projekt ein: Die Fakten werden zuerst festgestellt, erst dann schreibt eine KI einen Satz. Ein Sprachmodell erfindet nie die Struktur eines Systems. Es erklärt eine Struktur, die zuvor durch deterministische Analyse nachgewiesen wurde. Das ist die Qualitätsgrenze, die Architektinnen und Architekten, Revision und Fachbereich akzeptieren können. Praktisch führen zwei Wege in das Archiv.

Whitebox: aus dem Quellcode

SLIP, die Sysparency Legacy-Code Intelligence Platform unseres Partnerunternehmens Sysparency, liest den vollständigen Quellcode und die vorhandene Dokumentation eines Systems ein, unabhängig von der Technologie: SAP/ABAP, IBM Mainframe mit COBOL, PL/I und JCL, IBM i, NATURAL/ADABAS ebenso wie Java, Python, C/C++ oder JavaScript. Eine statische Analyse stellt die Fakten fest: Aufruf- und Abhängigkeitsgraphen, Lese- und Schreibzugriffe auf Daten, Maskenabläufe, Schnittstellen und Jobs. Darauf erklären KI-Agenten jeden Baustein zweimal, einmal für Prozessverantwortliche und einmal für Entwicklerinnen und Entwickler, und jede Aussage ist bis auf Programm und Zeile belegt. Das Ergebnis ist eine navigierbare Dokumentationsanwendung vom Systemdashboard über fachliche und technische Module bis zum einzelnen Baustein, ein abfragbarer Wissensgraph und ein Assistent, der Fragen wie „Was macht dieses System, und was geht kaputt, wenn ich es ändere?“ in Sekunden mit Quellenangabe beantwortet.

Blackbox: aus der beobachteten Nutzung

App2Spec, unsere eigene agentische Beratungsplattform, kommt ohne Quellcode aus. Ein KI-Agent bedient die Zielsoftware selbstständig wie eine Anwenderin oder ein Anwender, oder die Plattform zeichnet die Arbeit einer echten Benutzerin oder eines echten Benutzers auf, jeden Bildschirm und jedes Ereignis inklusive Screenshot. Daraus entstehen standardisierte Entitäten eines Wissensgraphen, also Screens, Bedienelemente, Navigationspfade, Datenfelder, abgeleitete Geschäftsregeln und End-to-End-Prozesse, und daraus eine IST-Spezifikation, die online publiziert und nach Word, PDF und Markdown exportiert wird. Dieser Weg ist überall dort wertvoll, wo der Quellcode nicht zugänglich ist: bei Standardsoftware mit umfangreichem Customizing oder bei Anwendungen externer Dienstleister.

Beide Wege ergänzen sich. SLIP liefert die Innensicht, App2Spec die Außensicht; wo beide vorliegen, deckt die Beobachtung auf, was der Code nicht zeigt, und der Code erklärt, was die Beobachtung nicht sieht.

Evidence-first: Das Archiv wird prüfbar

Eine Dokumentation ist so viel wert wie das Vertrauen, das sie genießt. Deshalb ist auf beiden Wegen jede Aussage auf ihre Evidenz rückführbar: auf Programm und Zeile im Quellcode oder auf Screenshot und Ereignisprotokoll. Wer eine Geschäftsregel anzweifelt, sieht mit einem Klick, wo sie steht oder wo sie beobachtet wurde. Weil die Codeanalyse deterministisch ist, ist sie reproduzierbar, und weil beide Wege automatisiert laufen, lässt sich der Lauf nach jedem Release wiederholen. Aus der Momentaufnahme wird eine lebende Dokumentation, die mit dem System Schritt hält, statt ihm hinterherzulaufen.

Die Angabe „Tage“ ist ein Erfahrungswert aus Sysparency- und ReqPOOL-Projekten, projektspezifisch validierbar und abhängig von Größe und Umfang des Systems. Sie ändert die Ökonomie der Ablöse: Der erste Schritt, der im genannten Bankfall mit einem Drittel des Budgets kalkuliert war, wird zur Vorbereitung.

Vom Archiv zum Arbeitsmittel

Ein Archiv, das gelesen werden kann, ist erst der Anfang. Der Wert entsteht, wenn die Organisation mit dem geöffneten Archiv arbeitet. In unseren Projekten sehen wir vier Situationen, in denen das unmittelbar geschieht:

• Ablöse und Ausschreibung. Die belegte IST-Spezifikation ist die Faktenbasis für Zielarchitektur, Ausschreibung und Migrationsplanung. Anbieter, Revision und Fachbereich arbeiten mit derselben, nachvollziehbaren Beschreibung.
• SAP-Transformation. Vor einer S/4HANA-Umstellung wird sichtbar, welche Eigenentwicklungen tatsächlich genutzt werden, welche Regeln sie tragen und welche wegfallen können. Das Scoping beruht auf einem Inventar, nicht auf einer Umfrage.
• Wissenssicherung vor dem Ausscheiden. Mainframe- und Kernsystembestände werden dokumentiert, solange die Wissensträgerinnen und Wissensträger noch im Haus sind und das Warum ergänzen können. Ihr Wissen wird als Kommentar am belegten Fakt festgehalten, nicht als loses Interviewprotokoll.
• Impact-Analysen im Betrieb. Die Frage, welche Programme, Datenflüsse und Schnittstellen eine Änderung berührt, wird zur Abfrage. Die Expertin oder der Experte prüft die Antwort, statt sie über Wochen zusammenzutragen.

Entscheidend ist, dass Dokumentation, Wissensgraph und Assistent beim Kunden verbleiben. Das Wissen über das System hängt danach nicht mehr an einzelnen Köpfen, und auch nicht an uns. Und es liegt zum ersten Mal in einer Form vor, die nicht nur Menschen lesen können: Ein typisierter, belegter Wissensgraph ist der Kontext, den KI-Agenten brauchen, um auf Bestandssystemen überhaupt sicher arbeiten zu können, in der Wartung ebenso wie in der agentischen Neuentwicklung nach dem Prinzip „Own the Spec, not the Code“. Wie aus der IST-Spezifikation das SOLL entsteht und welche Rolle der Wissensgraph dabei spielt, behandeln die folgenden Beiträge dieser Serie.

Für den Einsatz gelten die Zusagen, die für alle unsere Plattformen gelten: Sie sind Teil der Beratungsleistung, es fallen keine Lizenzkosten an, sie werden in der EU gehostet, und Kundendaten und Quellcode werden zu keinem Zeitpunkt für das Training von KI-Modellen verwendet.

Der nächste Schritt

Die Frage ist nicht, ob das Wissen der Pensionierten im Custom Code steckt. Die Frage ist, ob Ihre Organisation es lesen kann, bevor sie es braucht. Wie wir Bestandssysteme analysieren und dokumentieren, beschreibt unsere Leistung Reverse Engineering; die beiden Wege dorthin finden Sie auf den Seiten SLIP und App2Spec. In einem Expertengespräch klären wir, welches Ihrer Systeme sich für einen ersten Analyselauf eignet und welche Fragen dieser Lauf beantworten soll.