Modernisierung von Legacy-Mainframes
70–80 % der Mainframe-Modernisierungsprojekte scheitern. Nicht weil die Technologie falsch ist, sondern weil die Werkzeuge Code als Text statt als Topologie behandeln. Wir erstellen die Karte Ihrer Codebasis, bevor wir eine einzige Zeile anfassen, damit Ihre Migration dort gelingt, wo andere Millionen verbrannt und nichts geliefert haben.
1,52 Billionen $
Technische Schulden der USA
Pragmatic Coders, 2025
10 %/Jahr
Personalabwanderung bei COBOL
IEEE Spectrum, 2025
70–80 %
Misserfolgsquote der Modernisierung
Branchen-Metaanalyse, 2025
Die Werkzeuge, die „COBOL einfügen, Java erhalten" versprechen, erzeugen Code, der kompiliert. Das ist der einfache Teil. Der schwierige Teil ist der Code, den sie nicht sehen können.
Betrachten Sie ein Programm zur Verarbeitung von Überweisungen. Es enthält eine COMPUTE-Anweisung, die eine Variable namens TRN-LIMIT verwendet. Ein KI-Coding-Assistent übersetzt die Anweisung in eine Java- BigDecimal -Operation. Der Code kompiliert. Die Unit-Tests bestehen.
Im UAT bringt die erste Transaktion die Konsistenzprüfung der Datenbank zum Absturz.
Die Obduktion: TRN-LIMIT war in der Quelldatei, die die KI übersetzt hat, nicht definiert. Es war in einem Copybook definiert, das Tausende von Zeilen früher in der Ausführungskette eingebunden wurde. Dieses Copybook enthielt eine REDEFINES -Klausel, ein COBOL-Konstrukt, das es ermöglicht, dieselbe Speicheradresse je nach einem in einem völlig anderen Modul gesetzten Flag als zwei verschiedene Datentypen zu interpretieren.
Die KI sah TRN-LIMIT als einfaches numerisches Feld und nahm einen Standard-Ganzzahltyp an. Auf dem Mainframe enthielt diese Speicheradresse eine gepackte Dezimalzahl (COMP-3). Die Java-Anwendung schrieb beschädigte Binärdaten in die Datenbankspalte und löste damit einen Verstoß gegen die referenzielle Integrität aus.
Der Code war syntaktisch perfekt. Der Fehler war kontextuelle Blindheit. Die KI übersah eine Abhängigkeit, die außerhalb ihres Sichtfelds bestand.
Ein einzelnes COBOL-Programm kann über 40 Copybooks referenzieren. Jedes Copybook kann mit COPY weitere Copybooks einbinden. Variablendefinitionen können fünf Ebenen tief in der Einbindungskette liegen. Textbasierte KI-Werkzeuge sehen davon nichts.
Ihr COBOL läuft nicht eigenständig. CA-7 oder TWS planen 2.000–5.000 JCL-Jobs mit Abhängigkeitsketten. Job A schreibt einen Datensatz, den Job B um 2 Uhr nachts liest. Migrieren Sie das COBOL, aber übersehen Sie die JCL, und die Produktion bricht um Mitternacht zusammen.
Die gepackte Dezimalzahl COMP-3 von COBOL hat kein Java-Äquivalent. Ein Java- double führt Gleitkomma-Rundungsfehler ein. Selbst BigDecimal erfordert die explizite Konfiguration des Rundungsmodus (HALF_EVEN), um der ROUNDED-Klausel von COBOL zu entsprechen. Ein einziger falscher Cent summiert sich über Millionen von Transaktionen.
Jeder große Technologieanbieter verkauft mittlerweile Mainframe-Modernisierung. Hier ist, was jeder tatsächlich liefert und wo die Lücken bleiben.
| Anbieter / Ansatz | Was es tut | Typische Kosten | Was es übersieht |
|---|---|---|---|
| IBM Watsonx Code Assistant for Z | Agentische COBOL-zu-Java-Übersetzung mit ADDI-Abhängigkeitsanalyse. Multi-Agenten-Architektur (Orchestrate-, Architect-, Code-Agenten). Unterstützt PL/I und IMS. | 2 Mio. $+ (Enterprise-Lizenzierung + z/OS-Anforderung) | ADDI läuft auf z/OS und erzeugt während der Migration eine Anbieterbindung. Der Parser hat Schwierigkeiten mit COBOL-Konstrukten vor 1985 (ALTER-Anweisungen). Keine Tests auf Verhaltensäquivalenz. Keine Abbildung von JCL-Abhängigkeiten. |
| Anthropic Claude Code | KI-gestützte Codeanalyse, Dokumentation, Abhängigkeitsabbildung. Stark in den Discovery- und Explorationsphasen. Unterstützt inkrementelle Migration und API-Wrapping. | Nutzungsbasierte API-Preisgestaltung | Allzweck-KI. Kein integrierter Knowledge Graph zur Auflösung transitiver Abhängigkeiten. Behandelt weder JCL-Scheduling noch Tests auf Verhaltensäquivalenz oder regulatorische Prüfpfade. |
| Microsoft Azure Migration Factory | Modulare agentische Agenten über Semantic Kernel. COBOL-Expert- + Java-Expert-Agenten. Zielt auf Java Quarkus. Azure Copilot Migrationsagent in der Vorschau. | Azure-Verbrauch + Beratung | Azure-Bindung für die Zielplattform. Open-Source-Agenten sind Referenzimplementierungen, nicht produktionsreif für regulierte Umgebungen. Begrenzte CICS-/IMS-Unterstützung. |
| DXC Technology | Patentierte automatische Codekonvertierung (COBOL/RPG/JCL zu Java). Jahrzehntelange Mainframe-Expertise. Hybride Cloud- + Mainframe-as-a-Service-Modelle. | 1 Mio. $–10 Mio. $+ | Proprietäre Werkzeuge, begrenzte Transparenz hinsichtlich der Konvertierungslogik. Fokus auf Großunternehmen. Projektlaufzeiten von 18–36 Monaten sind üblich. |
| TCS / Infosys / Accenture | Praktiken großer Systemintegratoren mit proprietären Frameworks (MasterCraft, Cobalt). Massive Lieferteams. End-to-End-Programmmanagement. | 500 Tsd. $–5 Mio. $+ | Plattformzentrierter Ansatz. Sie implementieren Anbieterwerkzeuge, statt maßgeschneiderte Intelligenz aufzubauen. Overhead des großen SI-Engagement-Modells. Ein SI leitete eine 1-Mrd.-AUD-Bankmigration, die 5 Jahre dauerte und ihr Budget verdoppelte. |
| Micro Focus (OpenText) Visual COBOL | COBOL nativ auf .NET/JVM ausführen. Pragmatischer „Strangler-Fig"-Ausgangspunkt. Marktführer bei COBOL-Compilern. | 200 Tsd. $–500 Tsd. $ Lizenzierung | Keine Modernisierung, sondern Rehosting. COBOL-Logik bleibt COBOL. Technische Schulden bestehen weiter. Löst das Personalproblem nicht. |
| Eigenbau mit Open-Source-KI | XMainframe-LLM (7B/10,5B Parameter, 30 % besser als DeepSeek bei COBOL). Tree-sitter-Parsing. Maßgeschneiderte Pipelines. | Engineering-Zeit + Infrastruktur | Erfordert tiefgreifende COBOL- und Graph-Engineering-Expertise. Kein produktionsreifer COBOL-Parser deckt alle Konstrukte von IBM Enterprise COBOL v6.x ab. Hohes Risiko, Parser-Lücken in das Fundament einzubauen. |
Fünf Fähigkeiten, die jeweils eine spezifische Lücke in der Modernisierungs-Toolchain schließen. Wir sind anbieterneutral: Der Knowledge Graph funktioniert unabhängig davon, ob Ihr Ziel AWS, Azure, GCP oder On-Premises-Java ist.
Wir nehmen Ihren COBOL-Quellcode, Copybooks, JCL-Bibliotheken, DB2-Katalogexporte, CICS-Transaktionsdefinitionen und IMS-Segmenthierarchien in eine einheitliche Graph-Datenbank auf. Jede Variable, jede PERFORM-Kette, jede REDEFINES-Klausel, jede Batch-Abhängigkeit wird zu einer expliziten Graph-Kante. Wir greifen zu Neo4j, wenn komplexe Abfragen zur transitiven Hülle den Anwendungsfall dominieren, und zu Memgraph, wenn die Echtzeit-Traversierungsgeschwindigkeit für die interaktive Exploration entscheidend ist.
Der Graph verarbeitet während der Aufnahme etwa 200.000–300.000 Zeilen pro Tag. Für eine Codebasis mit 2 Mio. LOC sind 8–12 Wochen vom ersten Import bis zum validierten, abfragbaren Graph zu erwarten. Das Ergebnis ist ein dauerhaftes Asset: Ihre Codebasis als durchsuchbare Topologie statt als undurchsichtige Textdateien.
Bevor eine Codeübersetzung beginnt, führen wir eine Graph-Analyse über vier Dimensionen durch: Kopplungsscore (wie viele andere Module von diesem abhängen), REDEFINES-/COMP-3-Dichte (wie viele Datentyp-Fallen existieren), Anteil an totem Code (typischerweise 20–30 % der Codebasis) und Kritikalität der Batch-Planung (welche JCL-Jobs dieses Modul berühren und wann).
Das Ergebnis ist eine geordnete Extraktionssequenz für die Strangler-Fig-Migration. Module mit der geringsten Kopplung und den einfachsten Datentypen werden zuerst extrahiert. „Gott-Programme", die von über 50 anderen Modulen aufgerufen werden, werden zuletzt extrahiert. Diese Sequenzierung ist der Unterschied zwischen einem kontrollierten Rollout und einem Kaskadenausfall.
Unsere Übersetzungsagenten fragen den Knowledge Graph ab, bevor sie jedes Java-Modul generieren, und ziehen die vollständige transitive Hülle der Abhängigkeiten heran. Der Agent sieht die REDEFINES-Klausel im Copybook drei Verzeichnisse weiter. Er sieht die gepackte Dezimaldefinition, die das Rundungsverhalten bestimmt. Er generiert Java mit explizitem Parameterübergabe (Dependency Injection) anstelle des impliziten globalen Zustands von COBOL. Dann kompiliert er in einer Sandbox, führt Tests auf Verhaltensäquivalenz aus und korrigiert sich selbst.
Wir verwenden jeweils das Foundation-Modell, das zur Komplexität des Moduls passt. Für unkomplizierte PERFORM-zu-Methoden-Konvertierungen genügt ein kleineres Modell. Für Module mit verschachtelten REDEFINES, GOTO-Spaghetti, die eine Abflachung des Kontrollflusses erfordern, oder mit EXEC-CICS-eingebetteter Transaktionslogik setzen wir das leistungsfähigste verfügbare Modell ein und erweitern es um den vollständigen Graph-Kontext.
Der Teil, den die meisten Anbieter überspringen und an dem die meisten Migrationen scheitern. Wir bauen ein dreischichtiges Validierungssystem: symbolische Unit-Tests, die aus graphbasierten Kontrollflusspfaden generiert werden, Golden-Dataset-Replay mit erfassten Produktionstransaktionen, die Feld für Feld mit centgenauer Genauigkeit verglichen werden, und parallele Produktionsläufe, in denen beide Systeme 30–90 Tage lang Live-Transaktionen verarbeiten, bevor das Mainframe-Modul außer Betrieb genommen wird.
Finanzberechnungen erfordern BigDecimal mit dem Rundungsmodus HALF_EVEN, um der ROUNDED-Klausel von COBOL zu entsprechen. Datumsberechnungen erfordern die Handhabung des 6-stelligen Datumsformats von COBOL (YYMMDD) mit Jahrhundert-Windowing-Logik. Wir bauen diese Konvertierungsregeln in den Test-Harness ein, nicht in Ad-hoc-Patches, die während der QA entdeckt werden.
Wir parsen Ihre JCL-Job-Netzwerke, CA-7-/TWS-/Control-M-Abhängigkeitsketten und Batch-Verarbeitungssequenzen in den Knowledge Graph. Jeder JCL-Job wird zu einem Knoten mit Kanten zu den COBOL-Programmen, die er ausführt, den Datensätzen, die er liest und schreibt, und den Planungsbedingungen, von denen er abhängt (Zeit-Trigger, Datensatzverfügbarkeit, Abschluss des Vorgängers).
Wenn ein COBOL-Modul zu Java migriert wird, bauen wir gleichzeitig die äquivalente Planung in Ihrer Ziel-Orchestrierungsplattform auf (Apache Airflow, AWS Step Functions, Azure Data Factory oder Control-M auf verteilter Infrastruktur). Die Abhängigkeitskette bleibt erhalten und wird gegen die ursprüngliche CA-7-/TWS-Definition verifiziert. Eine typische Bank der mittleren Ebene hat 2.000–5.000 JCL-Jobs. Wir haben sie alle gesehen.
Eine Schritt-für-Schritt-Erklärung, wie graphbasierte Abhängigkeitsauflösung das häufigste Muster gescheiterter Migrationen verhindert.
Der Parser verarbeitet PROG-WIRE-01.cbl, trifft auf COPY CB-ACCT-LIMITS und folgt der Einbindungskette. Er baut AST-Knoten für jede Variablendeklaration auf, einschließlich derer in Copybooks, die 3 Ebenen tief verschachtelt sind.
Die Graph-Engine erstellt Kanten: PROG-WIRE-01 → IMPORTS → CB-ACCT-LIMITS. TRN-LIMIT → REDEFINES → TRN-LIMIT-ALPHA. LIMIT-TYPE-FLAG → CONTROLS_TYPE_OF → TRN-LIMIT. Dies erfasst die Tatsache, dass der Datentyp von TRN-LIMIT von einem Laufzeit-Flag in einem anderen Feld abhängt.
Der Graph traversiert nach außen: Welche anderen Programme binden ebenfalls CB-ACCT-LIMITS ein? Welche Programme setzen LIMIT-TYPE-FLAG? Welche JCL-Jobs führen diese Programme aus und in welcher Reihenfolge? Das Ergebnis ist eine vollständige Auswirkungskette. Eine Änderung der Übersetzung von TRN-LIMIT betrifft jedes Programm in dieser Kette.
Wenn der Übersetzungsagent PROG-WIRE-01 verarbeitet, ruft GraphRAG nicht nur die Quelldatei ab, sondern auch die Copybook-Definition, die REDEFINES-Beziehung, das Flag-Feld und alle Programme, die das Flag setzen. Der Agent generiert eine Java-Klasse mit einem typsicheren Union-Pattern: ein TransactionLimit -Objekt, das das Flag prüft, bevor es die zugrunde liegenden Bytes entweder als BigDecimal (gepackter Dezimalmodus) oder als String (Alphamodus) interpretiert.
Ohne den Graph: nimmt die KI an, dass TRN-LIMIT ein einfaches numerisches Feld ist, generiert ein long in Java, und die erste Überweisung beschädigt die Datenbank. Mit dem Graph: sieht die KI die vollständige Abhängigkeitskette und generiert typsicheren Code, der beide Interpretationen korrekt handhabt. Das ist der Unterschied zwischen einer Migration, die im UAT funktioniert, und einer, die in der Produktion funktioniert.
Vier Phasen, jede mit klaren Ergebnissen. Wir nennen keine 3-Jahres-Laufzeit und verschwinden dann. Jede Phase produziert Artefakte, die Ihnen gehören und die Sie unabhängig nutzen können.
Ergebnis: Bewertungsbericht + vorläufiger Knowledge-Graph-Prototyp
Ergebnis: Abfragbarer Knowledge Graph + geordnete Extraktionssequenz + Tool zur Auswirkungsanalyse
Ergebnis: Migrierte Java-Module in Produktion + aktualisierter Knowledge Graph + Planungsäquivalente
Ergebnis: Validiertes Produktions-Deployment + regulatorisches Dokumentationspaket + aktualisierter Graph
Beantworten Sie sieben Fragen zu Ihrer Umgebung. Die Bewertung identifiziert Ihren Reifegrad und die spezifischen Blocker, die vor dem Start eines Migrationsprojekts anzugehen sind – mit oder ohne Veriprajna.
Für eine Codebasis mit 2 Mio. LOC und typischer Komplexität (IBM Enterprise COBOL v6.x, eingebettetes DB2-SQL, 500+ Copybooks) dauert der Aufbau des Graphen 8 bis 12 Wochen. Die ersten 3 Wochen entfallen auf Parser-Konfiguration und -Validierung. COBOL-Dialekte variieren genug, dass wir verifizieren müssen, dass der Parser Ihre spezifische Verwendung von REDEFINES, OCCURS DEPENDING ON und EXEC-CICS-/SQL-Blöcken handhabt, bevor wir die vollständige Codebasis aufnehmen.
Die Wochen 4 bis 8 umfassen automatisierte Aufnahme, Entitätsextraktion und Beziehungsabbildung. Der Parser verarbeitet etwa 200.000–300.000 Zeilen pro Tag, aber der Engpass ist die Entitätsauflösung – konkret die Feststellung, dass ACCT-NUM in Programm A und ACCT-NUM in Copybook CB-ACCT-01 dieselbe Variable sind.
Die Wochen 9 bis 12 umfassen die Berechnung der transitiven Hülle und die Validierung. Wir führen Vollständigkeitsprüfungen des Graphen durch: Jedes PERFORM-Ziel muss zu einem Paragraphen auflösen, jede COPY-Anweisung muss zu einem Copybook auflösen, jede DB2-Tabellenreferenz muss zu einer Schemadefinition zuordnen. Lücken werden zur manuellen Überprüfung markiert. Das Ergebnis ist ein abfragbarer Knowledge Graph, in dem Sie Fragen stellen können wie „Was passiert, wenn ich INTEREST-RATE in CB-GLOBAL-01 ändere?" und eine vollständige Auswirkungskette über jedes Programm erhalten, das ihn direkt oder transitiv referenziert.
Ja, und wir empfehlen es nachdrücklich. Das Strangler-Fig-Muster ist der einzige Ansatz mit nachgewiesener Erfolgsbilanz bei der Mainframe-Migration. Vollständige Neuentwicklungen scheitern in 70–80 % der Fälle, weil sie versuchen, alles gleichzeitig zu ersetzen, und damit einen einzigen massiven Single Point of Failure schaffen.
Beim Strangler-Fig-Ansatz identifiziert der Knowledge Graph, welche Module die niedrigsten Kopplungsscores haben, also die wenigsten eingehenden Abhängigkeiten von anderen Modulen. Das sind Ihre Extraktionskandidaten. Wir beginnen typischerweise mit Batch-Reporting-Modulen oder eigenständigen Berechnungsroutinen, die aus DB2 lesen, aber keinen gemeinsamen Zustand aktualisieren. Der neue Java-Service läuft parallel zum Mainframe. Der Produktionsverkehr für diese spezifische Funktion wird an den neuen Service geleitet, während der Mainframe alles andere weiterhin abwickelt. Sie validieren die Verhaltensäquivalenz an echten Produktionsdaten, bevor das COBOL-Modul außer Betrieb genommen wird.
Die meisten Organisationen extrahieren im ersten Jahr 15 bis 20 Module, reduzieren den MIPS-Verbrauch um 20–30 % und erzeugen genügend Kosteneinsparungen, um die nächste Phase zu finanzieren. Der Knowledge Graph macht dies sicher, weil er Ihnen den Wirkungsradius jeder Extraktion zeigt. Wenn Modul A von 47 anderen Programmen aufgerufen wird, ist das nicht Ihr erster Extraktionskandidat. Wenn Modul B von 2 Programmen aufgerufen wird und aus 1 DB2-Tabelle liest, fangen Sie dort an.
Dies ist die Ebene, auf der die meisten Modernisierungsprojekte nach 6 bis 12 Monaten auf unerwartete Fehler stoßen. Ihre COBOL-Programme laufen nicht isoliert. Sie werden durch JCL-Job-Streams orchestriert, die von CA-7, TWS (Tivoli Workload Scheduler) oder Control-M verwaltet werden. Eine typische Bank der mittleren Ebene hat 2.000 bis 5.000 JCL-Jobs mit komplexen Abhängigkeitsketten: Job A muss abgeschlossen sein, bevor Job B startet, Job C läuft nur am letzten Geschäftstag des Monats, Job D löst eine CICS-Transaktion aus, die eine von Job E gelesene VSAM-Datei aktualisiert.
Wir parsen JCL zusammen mit COBOL in denselben Knowledge Graph. Jeder JCL-Job wird zu einem Knoten mit Kanten zu den COBOL-Programmen, die er ausführt, den Datensätzen, die er liest und schreibt, und den Planungsbedingungen, von denen er abhängt. Wenn wir ein COBOL-Modul zu Java migrieren, bauen wir gleichzeitig die äquivalente Planung in Ihrer Zielplattform auf, ob das Apache Airflow, AWS Step Functions oder Azure Data Factory ist. Die Abhängigkeitskette bleibt erhalten und wird gegen das Original verifiziert.
Wir haben Projekte erlebt, in denen die Codemigration einwandfrei gelang, die Produktion aber zusammenbrach, weil niemand den CA-7-Job abgebildet hatte, der jede Nacht um 2 Uhr einen Vorverarbeitungsschritt ausführte.
IBM Watsonx Code Assistant for Z (derzeit v2.8.20, mit Project Bob später im Jahr 2026) ist ein starkes Produkt mit tiefer Mainframe-Integration. Es benötigt IBM ADDI (Application Discovery and Delivery Intelligence), um seine Abhängigkeitsanalyse aufzubauen, und ADDI läuft auf z/OS. Das bedeutet, dass Ihre Werkzeuge zur Abhängigkeitsanalyse auf demselben Mainframe leben, von dem Sie wegmigrieren wollen. Es bedeutet außerdem, dass IBM die Analyseebene kontrolliert, was während der kritischsten Phase der Migration eine Anbieterbindung erzeugt.
Unser Knowledge Graph läuft außerhalb des Mainframes. Wir nehmen Quellcode-Exporte, JCL-Bibliotheken, DB2-Katalogexporte und Copybook-Repositorys auf. Der Graph lebt in Ihrer Cloud-Umgebung oder Ihrer On-Premises-Infrastruktur, unabhängig von der IBM-Lizenzierung. Zweitens konzentriert sich Watsonx auf die COBOL-zu-Java-Übersetzung. Wir konzentrieren uns zuerst auf das Verständnis und erst dann auf die Übersetzung. Der Knowledge Graph ist ein dauerhaftes Asset, das Auswirkungsanalyse, Dokumentationserstellung und Architektur-Governance noch lange nach Abschluss der Migration unterstützt.
Drittens hat der COBOL-Parser von ADDI dokumentierte Einschränkungen bei COBOL-Konstrukten vor 1985, insbesondere bei ALTER-Anweisungen und bestimmten verschachtelten REDEFINES-Mustern. Wir bauen maßgeschneiderte Parser-Erweiterungen für den Dialekt jedes Kunden.
Schließlich richtet sich die Preisgestaltung von IBM an Großunternehmen. Unser Engagement-Modell funktioniert für Institute der mittleren Ebene, bei denen ein IBM-Engagement von über 2 Mio. $ nicht im Budget liegt.
Verhaltensäquivalenz ist der Punkt, an dem die meisten KI-gestützten Migrationen auseinanderfallen. Code, der kompiliert und Unit-Tests besteht, kann dennoch falsche Ergebnisse liefern – wegen Rundungsunterschieden bei gepackten Dezimalzahlen, EBCDIC-zu-ASCII-Codierungsabweichungen oder REDEFINES-Speicherüberlagerungssemantik, die sich nicht in Java-Objekte übersetzen lässt.
Wir bauen einen dreischichtigen Validierungs-Harness. Schicht 1 ist die symbolische Äquivalenz: Wir generieren aus dem Knowledge Graph Unit-Tests, die jeden Zweig im ursprünglichen COBOL-Kontrollfluss abdecken, einschließlich Grenzfällen wie negativen Beträgen, Schutzmechanismen gegen Division durch Null und Schaltjahr-Datumsberechnungen. Schicht 2 ist Golden-Dataset-Replay: Wir erfassen eine repräsentative Menge von Produktionstransaktionen vom Mainframe (Eingabedatensätze, DB2-Lesevorgänge, CICS-Interaktionen) und spielen sie durch den neuen Java-Service ab. Die Ausgaben werden Feld für Feld verglichen. Für Finanzberechnungen verifizieren wir centgenaue Genauigkeit mittels BigDecimal mit HALF_EVEN-Rundung, um dem Verhalten der ROUNDED-Klausel von COBOL zu entsprechen.
Schicht 3 ist der Parallellauf in Produktion: Beide Systeme verarbeiten 30 bis 90 Tage lang gleichzeitig dieselben Live-Transaktionen. Abweichungen werden protokolliert, untersucht und behoben, bevor das Mainframe-Modul außer Betrieb genommen wird. Dies ist die längste Phase, aber auch die Phase, die die über 30 Jahre Produktion angesammelten Grenzfälle abfängt, die keine Testsuite vollständig antizipieren kann.
DORA (Digital Operational Resilience Act) ist seit dem 17. Januar 2025 vollständig in Kraft und betrifft direkt jedes EU-regulierte Finanzunternehmen, das Mainframe-Systeme betreibt. Artikel 11 verlangt IKT-Risikomanagement-Rahmenwerke, die regelmäßige Resilienztests und bedrohungsorientierte Penetrationstests auf Basis realer Angriffsszenarien umfassen. Die meisten Mainframe-Umgebungen wurden nicht für diese Art von Tests konzipiert. Sie können nicht ohne Weiteres eine z/OS-Replikatumgebung hochfahren, um Penetrationstests durchzuführen, ohne erhebliche Lizenz- und Infrastrukturkosten.
DORA verlangt außerdem detaillierte IKT-Asset-Inventare, Vorfallmeldungen innerhalb bestimmter Fristen und Drittparteien-Risikomanagement für kritische IKT-Dienstleister, was Ihren Mainframe-Anbieter einschließt. Die Modernisierung hilft auf zwei Arten. Erstens dient der Knowledge Graph selbst als das IKT-Asset-Inventar, das DORA verlangt. Er bildet jedes Programm, jeden Datenfluss, jede externe Abhängigkeit ab. Aufsichtsbehörden können ihn direkt abfragen.
Zweitens sind migrierte Komponenten, die auf Cloud-Infrastruktur laufen, von Natur aus leichter resilienzzutesten. Sie können bei Bedarf Testumgebungen hochfahren, Chaos-Engineering-Szenarien durchführen und Wiederherstellungsverfahren validieren, ohne die Produktion zu beeinträchtigen. Wir haben erlebt, wie Institute den Knowledge Graph als Nachweis in aufsichtsrechtlichen Prüfungen verwenden, um zu belegen, dass sie ihren Technologiebestand verstehen – sogar bevor die Migration abgeschlossen ist.
Die Methodik hinter dieser Lösungsseite gründet auf unserer veröffentlichten Forschung zu Legacy-Modernisierung und Knowledge-Graph-Architekturen.
Wie repository-bewusste Knowledge Graphs und GraphRAG das „Lost in the Middle"-Syndrom überwinden, das KI-Code-Übersetzung auf Enterprise-COBOL-Systemen scheitern lässt.
Eine MIPS-Reduktion von 20–30 % im 1. Jahr spart für ein Institut der mittleren Ebene typischerweise 500 Tsd. $–2 Mio. $ jährlich.
Die Knowledge-Graph-Bewertung dauert 4–6 Wochen. Sie erhalten eine vollständige Abhängigkeitskarte Ihrer Codebasis, einen Bericht über toten Code und eine geordnete Extraktionssequenz – ob Sie mit der Migration fortfahren oder nicht. Die Bewertung selbst ist ein dauerhaftes Asset.