Über alle Technologien hinweg

Die Anwendungslandschaft eines großen Unternehmens ist selten aus einem Guss: Ein Großrechner mit Programmen aus den achtziger Jahren führt die Konten, ein ERP-System mit zwei Jahrzehnten Eigenentwicklungen steuert Logistik und Finanzen, und dazwischen laufen Individualanwendungen in Java, Python oder JavaScript, die Fachbereiche und Dienstleister gebaut haben. Wer diese Landschaft modernisieren will, bekommt für jede Technologie andere Fachleute, andere Werkzeuge und andere Dokumente. Der vierte und letzte Beitrag dieser Serie zeigt, warum agentisches Reverse Engineering über alle Technologien hinweg mit derselben Methode arbeitet, was je Technologie tatsächlich anders ist und warum erst ein gemeinsamer Wissensgraph die Landschaft als Ganzes verständlich macht.

Drei Technologiewelten, ein Problem

In unseren Projekten treffen wir fast immer auf dieselben drei Welten.

Mainframe. COBOL, PL/I und JCL auf IBM-Großrechnern, IBM i, NATURAL mit ADABAS: Diese Systeme führen bei Banken, Versicherungen, Sozialversicherungen und Verkehrsbetrieben bis heute die Kernbestände, also Konten, Verträge, Leistungen und Abrechnungen. Die Menschen, die sie geschrieben haben, sind vielfach schon in Pension oder stehen kurz davor.

ERP. Jede große SAP-Landschaft besteht aus zwei Systemen. Das erste ist der SAP-Standard, dokumentiert und gewartet vom Hersteller. Das zweite ist das, was das Unternehmen in zwanzig oder dreißig Jahren darauf gebaut hat: Eigenentwicklungen in den Z- und Y-Namensräumen, Erweiterungen, Modifikationen, User Exits, BAdI-Implementierungen, Schnittstellen zu Werken und Partnern, Batch-Ketten für den Periodenabschluss. In großen Industriekonzernen umfasst dieses zweite System nach dem Whitepaper von Sysparency zur Legacy-Code Intelligence Platform (Juli 2026) häufig Zehntausende Objekte je Instanz, und genau dort liegt die Differenzierung des Unternehmens.

Individualsoftware. Anwendungen in Java, C/C++, Python oder JavaScript, meist in mehreren Generationen von Frameworks, oft von wechselnden Teams und Dienstleistern entwickelt. Manche liegen im Quellcode vor, andere nur als lauffähige Anwendung, etwa wenn es den Dienstleister nicht mehr gibt oder eine Standardsoftware so weit angepasst wurde, dass das Customizing selbst zur Individualsoftware geworden ist.

So verschieden die drei Welten technisch sind, so gleich ist ihr Zustand: Die Dokumentation ist lückenhaft, veraltet oder liegt in Köpfen. Das erzeugt dieselben drei Risiken, gleichgültig ob die Logik in COBOL, ABAP oder Java steht: ein Transformationsrisiko, weil der Umfang geschätzt statt gezählt wird; ein Betriebsrisiko, weil jede Änderung unbekannte Nebenwirkungen haben kann; und ein Wissensrisiko, weil das Verständnis mit den Menschen geht. Im ersten Beitrag dieser Serie habe ich das Bestandssystem deshalb als Wissensarchiv beschrieben. Die Frage, die dieser Beitrag beantwortet, lautet: Braucht jedes dieser Archive eigene Werkzeuge und eigene Fachleute?

Warum die Methode nicht von der Technologie abhängt

Die Antwort ist nein, und der Grund liegt in der Reihenfolge der Analyse. Agentisches Reverse Engineering, wie wir es mit SLIP, der Sysparency Legacy-Code Intelligence Platform, betreiben, arbeitet in drei Stufen, und nur die erste davon kennt die Technologie.

1. Symbolische Analyse. Eine deterministische, statische Analyse liest jeden Baustein des Systems ein und modelliert Syntax und Logik exakt: Aufruf- und Abhängigkeitsgraphen, Lese- und Schreibzugriffe auf Daten, Bildschirm- und Prozessflüsse, Schnittstellen und Jobs. Hier steckt das technologiespezifische Wissen: Ein COBOL-Programm mit seinen Copybooks wird anders geparst als ein ABAP-Report mit seinem Selektionsbild oder ein Java-Service mit seinen Annotationen. Das Ergebnis ist aber in allen Fällen dasselbe: bewiesene Fakten über das System, vollständig und reproduzierbar.
2. Agentische Interpretation. KI-Agenten lesen das symbolische Modell und den Quellcode und erklären jeden Baustein zweimal, fachlich für die Prozessverantwortlichen und technisch für Architektur und Entwicklung. Die Agenten erfinden keine Struktur; sie erklären eine, die in der ersten Stufe bewiesen wurde. Diese Stufe ist für COBOL und Java identisch.
3. Konsolidierung im Wissensgraphen. Fakten und Erklärungen werden als typisierte Knoten und Beziehungen gespeichert, versioniert je Analyselauf und mit Quellenangabe bis auf Programm und Zeile. Auch diese Stufe ist technologieneutral: Ein Batch-Job ist ein Batch-Job, ob er in JCL oder als SAP-Jobkette definiert ist.

Die Ontologie des Graphen, die ich im dritten Beitrag beschrieben habe, ist damit der eigentliche Grund für die Technologieunabhängigkeit. Programme, Tabellen, Schnittstellen, Bildschirme, Jobs und Geschäftsregeln sind dieselben Entitätstypen, gleichgültig aus welcher Sprache sie stammen. Was sich unterscheidet, ist der Weg dorthin, nicht das Ziel.

Die Syntax ist verschieden. Die Frage ist immer dieselbe: Was tut dieses System, und was geht kaputt, wenn wir es ändern?

Wo kein Quellcode vorliegt, greift der zweite Weg, den ich im zweiten Beitrag beschrieben habe: App2Spec beobachtet die Anwendung aus Sicht der Anwenderinnen und Anwender und legt Screens, Datenfelder, Geschäftsregeln und Prozesse in derselben Ontologie ab. Auch die Blackbox mündet also im selben Graphen.

Was je Technologie tatsächlich anders ist

Technologieunabhängig heißt nicht, dass die Analyse überall dieselben Schwerpunkte hat. Jede Welt hat Stellen, an denen sich ihr Wissen konzentriert.

Mainframe: Die Logik läuft nachts

Wer ein Mainframe-System nur über seine Bildschirme kennt, kennt die Hälfte. Der andere Teil sind die Batch-Ketten: Jobs, die in JCL definiert sind, in fester Reihenfolge laufen, Dateien erzeugen, die der nächste Job liest, und am Ende den Tagesabschluss oder die Abrechnung liefern. Die Analyse muss diese Ketten als Ganzes abbilden, mit jeder Abhängigkeit zwischen Job, Programm und Datei. Dazu kommen die geteilten Datenstrukturen: Ein Copybook, das viele Programme einbinden, ist die Stelle, an der eine kleine Änderung große Wirkung hat. Der Graph macht sichtbar, welche Programme eine Struktur lesen und welche sie schreiben.

ERP: Das zweite System hinter dem Standard

In SAP-Landschaften ist die erste Aufgabe die Abgrenzung: Was ist Standard, was ist Eigenentwicklung, und wo greift die Eigenentwicklung in den Standard ein? Die Analyse folgt dem Custom Code über fünf Schichten, wie sie das Sysparency-Whitepaper beschreibt: von der Oberfläche (Fiori-Apps, Dynpro- und Selektionsbilder) über die Geschäftslogik (Eigenentwicklungen, Erweiterungen, User Exits, BAdIs) und den Datenzugriff (Tabellen, Views, Lese- und Schreibpfade) bis zur Integration (RFC, IDoc, APIs) und zum Betrieb (Jobs, Jobketten, Periodenabschluss). Für S/4HANA-Vorhaben und Clean-Core-Strategien ist das die Faktenbasis, die den Umfang zählbar macht: Welche Eigenentwicklungen werden noch aufgerufen, welche schreiben in Standardtabellen, welche lassen sich durch Standard ersetzen? Ohne diese Basis wird nach Schätzung geplant, mit ihr nach Inventar.

Individualsoftware: Viele Generationen, manchmal kein Code

Individualanwendungen sind technisch die vertrauteste Welt und organisatorisch oft die unübersichtlichste. Über die Jahre haben mehrere Teams mit mehreren Frameworks gebaut; Geschäftsregeln verteilen sich auf Services, Datenbankprozeduren und Oberfläche. Die Analyse muss hier vor allem Schichten und Schnittstellen sauber trennen und Regeln dort finden, wo sie tatsächlich implementiert sind, nicht wo die Architektur sie vorgesehen hatte. Liegt kein Quellcode vor, übernimmt App2Spec: Ein KI-Agent bedient die Anwendung oder zeichnet die Arbeit echter Benutzerinnen und Benutzer auf, und aus Screenshots und Ereignisprotokollen entsteht die IST-Spezifikation. In der Praxis kombinieren wir hier meist beide Wege.

Ein Graph für die ganze Landschaft

Der eigentliche Nutzen der Technologieunabhängigkeit zeigt sich nicht innerhalb eines Systems, sondern zwischen den Systemen. Geschäftsprozesse halten sich nicht an Technologiegrenzen. Ein typischer Ablauf: Ein COBOL-Batch erzeugt nachts eine Bewegungsdatei, eine SAP-Schnittstelle liest sie ein und bucht, und ein Java-Portal zeigt dem Fachbereich am Morgen das Ergebnis. Wer die Schnittstelle stilllegen oder das Format ändern will, muss alle drei Seiten kennen. Solange jede Technologie ihre eigene Dokumentation hat, beantwortet diese Frage niemand vollständig, und Änderungsfenster werden mit Sicherheitspuffern gegen unbekannte Nebenwirkungen geplant.

Landen alle Systeme im selben Graphen, mit Beziehungen über Systemgrenzen hinweg, wird aus der wochenlangen Untersuchung eine Abfrage: Welche Objekte in welchen Systemen hängen an dieser Schnittstelle, welche Jobs warten auf ihren Abschluss, welche Tabellen werden dadurch geschrieben? Der agentische Assistent beantwortet sie in Sekunden, mit Zitat auf jede Fundstelle, und die Expertinnen und Experten prüfen die Antwort, statt sie zusammenzutragen. Für Agenten gilt dasselbe: Über das Model Context Protocol wird der Graph zur verlässlichen Kontextquelle für jede agentische Umsetzung auf Bestandssystemen, gleichgültig in welcher Technologie das Zielsystem gebaut wird.

Drei Eigenschaften des Graphen machen das über Technologien hinweg tragfähig:

• Ein Standard. Jedes System durchläuft dieselbe Pipeline, deshalb sind die Ergebnisse vergleichbar: Sparten, Regionen und Gesellschaften sind einheitlich dokumentiert, und Portfolio-Entscheidungen beruhen auf Inventar statt auf Umfragen.
• Versionierung. Jeder Analyselauf ist eine Version. Die Dokumentation lässt sich nach jedem Release wiederholen, damit die Ausgangslage nicht mitten im Programm veraltet.
• Quellenangabe. Jede Aussage führt zur Zeile im Code oder zum Screenshot. Vertrauen ist prüfbar, nicht vorausgesetzt.

Was das für Modernisierungsprogramme bedeutet

Aus unseren Projekten leiten sich vier praktische Konsequenzen ab.

• Mit einem System beginnen, nicht mit der Landschaft. Wir starten mit einem repräsentativen, geschäftskritischen System, idealerweise einem, zu dem gerade eine konkrete Transformationsfrage offen ist. Die Analyse eines Systems liegt nach unseren Erfahrungswerten aus ReqPOOL-Projekten in Tagen vor, nicht in Monaten; die Werte sind projektspezifisch validierbar. Die Expertinnen und Experten des Kunden prüfen Dokumentation und Assistent an ihren schwierigsten aktuellen Fragen. Erst danach folgt der Ausbau Welle für Welle.
• Die Technologie des Bestands entscheidet nicht über die Technologie des Ziels. Weil die IST-Spezifikation im Graphen technologieneutral ist, kann das Zielsystem in jeder Technologie entstehen. Aus dem Graphen führen wir die IST-Spezifikation in den ReqPOOL Requirements Manager, entwickeln sie mit dem Fachbereich zum SOLL weiter und übergeben sie als maschinenlesbaren Bauauftrag an reqCoder, unseren vollständigen, vollautomatisierten agentischen Software Development Lifecycle, der bei uns intern bereits im Einsatz ist. Das ist „Own the Spec, not the Code“ in seiner konsequentesten Form: Der COBOL-Code bleibt Geschichte, die Spezifikation wird Zukunft.
• Entscheidungen je Modul, nicht je Technologie. Weiterbetrieb, Modernisierung oder Ablöse sind keine Fragen, die man für „den Mainframe“ beantwortet. Transformationsempfehlungen entstehen auf System-, Modul- und Bausteinebene, ausgerichtet am Projektziel. Manches Modul läuft stabil weiter, manches wird neu gebaut, manches durch Standard ersetzt.
• Menschen validieren, wo es auf fachliche Wahrheit ankommt. Der Code kennt jede Regel, aber nicht ihre Absicht. Ob eine Rundungsregel gewollt ist oder ein zur Gewohnheit gewordener Fehler, entscheidet der Fachbereich gemeinsam mit unseren Beraterinnen und Beratern. Die Werkzeuge nehmen den Menschen das Zusammentragen ab, nicht das Entscheiden.

Für regulierte Branchen gilt über alle Technologien hinweg: Die Quellcode-Extraktion liest Code und Metadaten, keine Geschäftsdaten; die Plattformen werden in der EU gehostet; Kundendaten und Quellcode werden nicht zum Training von KI-Modellen verwendet; und in ReqPOOL-Beratungsprojekten entstehen keine Lizenzkosten für die eingesetzten Werkzeuge. Sie bezahlen Expertise und Aufwand; Dokumentation, Wissensgraph und Assistent bleiben bei Ihnen.

Der nächste Schritt

Mit diesem Beitrag schließt die Serie zum agentischen Reverse Engineering: vom Bestand als Wissensarchiv über die Rekonstruktion der Spezifikation und den Wissensgraphen bis zur Landschaft als Ganzes. Wenn in Ihrem Haus Mainframe, ERP und Individualsoftware nebeneinander laufen und eine Modernisierung ansteht, ist die technologieübergreifende IST-Aufnahme der erste Schritt. Wie wir dabei vorgehen, beschreibt unsere Leistung Reverse Engineering; die Whitebox-Plattform im Detail finden Sie auf der Seite SLIP. In einem Expertengespräch klären wir, mit welchem System Sie sinnvoll beginnen.