Der Wissensgraph als Fundament agentischer Modernisierung

In den ersten beiden Beiträgen dieser Serie ging es darum, dass das Wissen über ein Unternehmen im Bestandscode steckt und wie sich daraus eine belegte IST-Spezifikation rekonstruieren lässt. Offen blieb eine Frage, die über Erfolg oder Scheitern agentischer Modernisierung entscheidet: In welcher Form muss dieses Wissen vorliegen, damit KI-Agenten damit arbeiten können? Meine Antwort ist eindeutig: nicht als Dokument, sondern als Wissensgraph. Dieser Beitrag erklärt, was das bedeutet, wie ein solcher Graph entsteht und warum er das Fundament jedes agentischen Vorhabens auf Bestandssystemen ist.

Agenten sind so gut wie ihr Kontext

Wer heute einen KI-Agenten auf ein Bestandssystem ansetzt, erlebt schnell die Grenze des Ansatzes. Der Agent bekommt ein Fachkonzept von 2011, ein Wiki mit unklarem Stand und Zugriff auf einige Millionen Zeilen Code. Was er daraus macht, ist eine Interpretation: Er sucht Textstellen, kombiniert sie und formuliert eine plausible Antwort. Ob die Rundungsregel für eine bestimmte Vertragsart noch gilt, ob die Schnittstelle, die er anpassen soll, nachts von einem Batch benötigt wird, ob die Tabelle noch von einem zweiten Programm geschrieben wird: Das steht in keinem Dokument, und wo es nicht steht, rät das Modell. Halluzinierte Anforderungen, übersehene Abhängigkeiten und Nacharbeit fressen den Effizienzgewinn auf, der das Vorhaben begründet hat.

Das Problem liegt nicht beim Modell, sondern bei der Form des Wissens. Dokumente sind für Menschen geschrieben, die den Kontext kennen und Lücken aus Erfahrung schließen. Ein Agent hat diese Erfahrung nicht. Er braucht Fakten, die er abfragen kann: welches Programm welche Tabelle schreibt, welcher Job welchen auslöst, unter welcher Bedingung eine Regel greift, und für jede dieser Aussagen den Beleg im Quellcode oder in der beobachteten Nutzung.

Im ersten Beitrag dieser Serie habe ich beschrieben, warum Legacy ein Wissensarchiv ist; im zweiten, wie wir daraus das belegte IST rekonstruieren. Der dritte Schritt ist die Frage der Form: Maschinenlesbares Bestandswissen ist die Voraussetzung dafür, dass agentische Modernisierung überhaupt beginnen kann.

Was ein Wissensgraph ist und was er enthält

Ein Wissensgraph speichert das Wissen über ein System als typisierte Knoten und Beziehungen. Knoten sind die Dinge, aus denen ein System besteht: Programme, Erweiterungen, Tabellen, Schnittstellen, Masken, Batchjobs, Geschäftsregeln. Beziehungen beschreiben, was zwischen ihnen tatsächlich passiert: Ein Programm ruft ein anderes auf, schreibt in eine Tabelle, wird von einem Job ausgelöst, rendert eine Maske, protokolliert in ein Audit-Log. Jeder Knoten trägt eine fachliche und eine technische Beschreibung, die Fundstellen im Quellcode und die Version des Analyselaufs, aus dem er stammt.

Drei Eigenschaften unterscheiden diesen Graphen von jeder Dokumentensammlung:

• Typisiert. Entitäten und Beziehungen folgen einem festen Schema. Eine Abfrage liefert Fakten, keine Textstellen: nicht „Dokumente, in denen die Tabelle vorkommt“, sondern „die sechs Programme, die in die Tabelle schreiben“.
• Versioniert. Jeder Analyselauf ist eine Version. Was sich zwischen zwei Releases geändert hat, wird sichtbar und prüfbar, statt in der Historie eines Wikis zu verschwinden.
• Belegt. Jede Aussage führt auf Quellzeilen im Programm oder auf Screenshot und Ereignisprotokoll zurück. Vertrauen wird verifiziert, nicht vorausgesetzt.

Wir befüllen den Graphen aus zwei Richtungen. SLIP, die Sysparency Legacy-Code Intelligence Platform, liest den Quellcode ein und stellt in einer deterministischen, symbolischen Analyse die Fakten fest: Aufruf- und Abhängigkeitsgraphen, Lese- und Schreibzugriffe, Bildschirm- und Prozessflüsse, Schnittstellen und Jobs. App2Spec beobachtet die Anwendung in der Nutzung und überführt Screenshots und Ereignisse in standardisierte Entitäten: Screens, Bedienelemente, Navigationspfade, Datenfelder, Geschäftsregeln und Prozessschritte. Beide Wege legen ihre Ergebnisse als typisierte, belegte Entitäten nach einem festen Schema ab, und jedes analysierte System wird nach demselben Standard abgebildet. Deshalb ist ein Mainframe-Kernsystem im Graphen genauso strukturiert wie eine Web-Anwendung, und deshalb lassen sich Aussagen über Systemgrenzen hinweg verbinden.

Symbolisch zuerst, generativ danach

Die Reihenfolge, in der der Graph entsteht, ist keine technische Nebensache. Zuerst stellt die symbolische Analyse die Struktur fest: vollständig, deterministisch, reproduzierbar. Erst danach lesen KI-Agenten 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 KI erfindet keine Struktur; sie erklärt eine bewiesene. Im Graphen bleiben beide Ebenen getrennt: die exakten Fakten aus der Analyse und die erzeugten Erklärungen, jede mit Verweis auf die Quelle. Das ist der Qualitätsmaßstab, den Revision und Architektur akzeptieren können, und es ist der Grund, warum Agenten dem Graphen trauen dürfen, obwohl sie Dokumenten nicht trauen sollten.

Vom Artefakt zur Infrastruktur: der Graph als Faktenbasis für Agenten

Seinen vollen Wert entfaltet der Wissensgraph, wenn er über das Model Context Protocol (MCP) an agentische KI-Systeme angebunden wird. Jede kompatible Agentenplattform, ob Coding-Agent, Transformations-Copilot oder Unternehmensassistent, fragt den Graphen direkt ab und erhält exakte, belegte Fakten über die Landschaft. Der Agent muss den Bestand nicht mehr aus Dokumenten deuten; er fragt nach.

Dokumentation war ein Artefakt. Für Agenten ist sie Infrastruktur.

Das kehrt die übliche Ökonomie von KI im Unternehmen um. Bisher baute jedes KI-Vorhaben seinen Kontext selbst auf: Dokumente sammeln, Code einlesen, Expertinnen und Experten befragen, und beim nächsten Projekt von vorn. Mit einem zentralen Graphen erben alle agentischen Initiativen dasselbe Fundament. Vier Anwendungen zeigen den Unterschied:

• Impact-Analyse in Sekunden. Die Frage „Wir wollen diese Schnittstelle abschalten. Welche Programme schreiben darüber in den Materialstamm, und welche Batchjobs brechen?“ erforderte bisher tage- bis wochenlange Recherche über Teams und Zeitzonen hinweg. Mit dem Graphen ist sie eine Abfrage; Expertinnen und Experten prüfen die Antwort, statt sie zusammenzutragen.
• Evidenzbasiertes Scoping. Ob S/4HANA-Transformation, Carve-out oder Ablöse: Der Umfang wird aus dem Inventar gezählt, nicht aus Interviews geschätzt.
• Testableitung. Aus belegten Geschäftsregeln und Prozessflüssen entstehen Testfälle, die das tatsächliche Verhalten des Bestands absichern, nicht das erinnerte.
• Fundierte agentische Entwicklung. Coding-Agenten, die im agentischen Software Development Lifecycle das Zielsystem bauen, fragen den Graphen nach Schnittstellen, Datenstrukturen und Regeln des Bestands, statt sie zu raten.

Der letzte Punkt ist für uns der entscheidende. Wenn reqCoder, der vollständige, vollautomatisierte agentische Software Development Lifecycle von ReqPOOL, der bei uns intern bereits im Einsatz ist, aus einer SOLL-Spezifikation Software erzeugt, dann stammt das IST in dieser Spezifikation aus dem Graphen, und der Kontext für die Entscheidungen der Agenten ebenfalls. Ohne diesen Graphen bleibt agentische Entwicklung auf Bestandssystemen ein Experiment; mit ihm wird sie abnahmefähig.

Ein Graph für die ganze Landschaft

Ein Wissensgraph zeigt seinen Wert nicht am einzelnen System, sondern an der Landschaft. Große Organisationen betreiben nicht ein Bestandssystem, sondern Dutzende: ERP-Instanzen je Region, Mainframe-Kernsysteme, Individualsoftware, Standardsoftware mit Customizing. Nach Analysen von Sysparency umfasst allein die Eigenentwicklung auf einer SAP-Instanz in großen Industriekonzernen häufig zehntausende Objekte. Solange jedes System für sich dokumentiert wird, bleiben die Kanten dazwischen unsichtbar: die Schnittstelle, über die das Lagersystem auf den Abschluss eines Batches im ERP wartet, die Tabelle, die von drei Systemen gelesen wird.

Weil alle Systeme in denselben Graphen laufen, entstehen genau diese systemübergreifenden Beziehungen. Drei Prinzipien machen das möglich:

1. Ein Standard. Jedes System durchläuft dieselbe Pipeline und wird nach demselben Schema abgelegt. Divisionen, Regionen und Gesellschaften werden vergleichbar.
2. Wiederholbar auf Abruf. Die Analyse wird nach jedem Release und vor jedem Programm erneut ausgeführt. Eine einmalige Studie beschreibt die Landschaft, wie sie an einem Tag war, und altert sofort; der Graph folgt der Landschaft, statt ihr hinterherzulaufen.
3. Welle für Welle. Der Einstieg beginnt mit einem System, die Ausrollung erfolgt in Wellen. Jede Welle fügt Systeme demselben Graphen hinzu, sodass sich der Wert addiert, statt in Projektsilos zu zerfallen.

Ich halte diesen Punkt für unterschätzt. Die meisten Modernisierungsprogramme scheitern nicht am einzelnen System, sondern an den Abhängigkeiten, die niemand kannte. Ein Graph, der die Landschaft abbildet, macht die Wirkung einer Änderung bekannt, bevor sie gemacht wird.

Der Graph gehört der Organisation

Ein Fundament ist nur dann eines, wenn es bleibt. Deshalb sind für uns drei Zusagen nicht verhandelbar. Dokumentation, Wissensgraph und Assistent verbleiben als Arbeitsmittel beim Kunden; das Wissen über die Systeme hängt nicht mehr an einzelnen Köpfen und nicht an uns. Der Graph hängt nicht am Modellanbieter: Die Fakten stammen aus der symbolischen Analyse und nicht aus dem Sprachmodell; wird das Modell gewechselt, bleiben sie erhalten, und nur die erzeugten Erklärungen werden neu geschrieben. Und der Zugriff ist steuerbar, je Rolle, je System und je Agent, sodass ein Coding-Agent nur das sieht, was er für seine Aufgabe braucht.

Dazu kommen die Rahmenbedingungen, die für Banken, Versicherungen, Energieversorger und die öffentliche Verwaltung entscheidend sind: Die Extraktion liest Code und Metadaten, keine Geschäftsdaten; die Analyse läuft in einer kundenspezifischen Umgebung in der EU; Kundendaten und Quellcode werden zu keinem Zeitpunkt für das Training von KI-Modellen verwendet; und in ReqPOOL-Beratungsprojekten entstehen keine Lizenzkosten für die eingesetzten Plattformen. Sie bezahlen Expertise und Aufwand. Der Graph gehört Ihnen.

Was das für Ihr Modernisierungsprogramm bedeutet

In unseren Projekten hat sich ein Vorgehen bewährt, das mit dem Graphen beginnt und nicht mit der Zielarchitektur:

1. Ein System auswählen. Ein repräsentatives, geschäftskritisches System, idealerweise eines, zu dem gerade eine Transformationsfrage offen ist.
2. Die Pipeline vollständig durchlaufen. Extraktion, symbolische Analyse, agentische Interpretation und Konsolidierung im Graphen; nach unseren Erfahrungswerten aus ReqPOOL-Projekten in Tagen, projektspezifisch validierbar.
3. Gegen die Realität testen. Ihre Expertinnen und Experten stellen dem Graphen und dem Assistenten ihre schwierigsten aktuellen Fragen, auch über MCP aus ihren eigenen Agentenwerkzeugen heraus.
4. Über die Ausrollung entscheiden. Welle für Welle die Landschaft ergänzen und den Graphen zur Grundlage der SOLL-Spezifikation und der agentischen Umsetzung machen.

Die Reihenfolge ist wichtig, weil sie die teuerste Erkenntnis nach vorn holt. Wer erst das SOLL entwirft und dann den Bestand versteht, findet die Abhängigkeiten in der Abnahme. Wer mit dem Graphen beginnt, kennt sie am ersten Tag.

Der nächste Schritt

Wenn Sie agentische Werkzeuge auf Ihre Bestandssysteme ansetzen wollen, ist der Wissensgraph der erste Schritt, noch vor dem ersten Agenten. Wie wir Bestandssysteme aus Quellcode und Nutzung in einen belegten Graphen überführen, beschreibt unsere Leistung Reverse Engineering; die Plattform, die den Graphen aus dem Quellcode aufbaut und über MCP für Agenten öffnet, finden Sie auf der Seite zu SLIP. In einem Expertengespräch klären wir, mit welchem System Sie beginnen sollten und welche Transformationsfrage sich als erster Test eignet.