Ein Beitrag von Uwe Graf, Head of Consulting bei EasiRun.
Wenn heute über die Modernisierung von COBOL-Anwendungen gesprochen wird, dauert es meist nicht lange, bis künstliche Intelligenz ins Spiel kommt. Code analysieren, Geschäftsregeln erkennen, Java erzeugen. Was vor wenigen Jahren noch nach einem aufwendigen Migrationsprojekt klang, soll plötzlich auf Knopfdruck funktionieren.
KI eröffnet tatsächlich neue Möglichkeiten. Trotzdem lohnt sich gerade jetzt ein Blick auf eine andere Frage: Muss eine bewährte Anwendung überhaupt neu interpretiert werden, wenn wir ihre vorhandene Logik kontrolliert in eine neue technische Umgebung übertragen können?
Genau dieser Gedanke steht seit Langem hinter P3/COBOL. Und eine aktuelle Forschungsarbeit zur Übersetzung von Fortran nach Python liefert ein interessantes Argument dafür, warum deterministische Verfahren bei der Modernisierung weiterhin eine wichtige Rolle spielen.
Was die Fortran-Forschung mit COBOL zu tun hat
Wie LegacyIT.de in seinem Beitrag über den Fortran-Transpiler FGPT berichtet, setzen Forscher des französischen Institut Pierre-Simon Laplace bei der Übertragung wissenschaftlicher Anwendungen bewusst auf klassische Compilertechnik. Der Quellcode wird strukturiert analysiert, Abhängigkeiten werden ermittelt und die Übersetzung erfolgt über definierte Zwischenschritte. Ziel ist es, die ursprüngliche Programmsemantik zu erhalten und die Ergebnisse reproduzierbar überprüfen zu können.
Die Autoren grenzen ihren Ansatz ausdrücklich von einer alleinigen Übersetzung durch Large Language Models ab. Bei großen Codebeständen reichen plausibel aussehende Ergebnisse nicht aus. Konsistente Transformationen, numerische Genauigkeit und der Vergleich mit Referenzergebnissen sind entscheidend. Das zugrunde liegende Forschungspapier „A Fortran General-Purpose Transpiler: Proof of Concept“ beschreibt diesen Ansatz und seine bisherige Erprobung.
Das ist keine Aussage darüber, dass KI für Modernisierung ungeeignet wäre. Es ist vielmehr eine Erinnerung daran, dass Codegenerierung und der Nachweis korrekten Verhaltens zwei unterschiedliche Aufgaben sind.
Für COBOL-Anwendungen in Banken, Versicherungen und anderen Unternehmen ist diese Unterscheidung besonders wichtig. Dort reicht es nicht, wenn eine neue Implementierung in den meisten Fällen dasselbe Ergebnis liefert. Auch seltene Geschäftsvorfälle, Rundungsregeln, Datenformate und historisch gewachsene Sonderfälle müssen berücksichtigt werden.
P3/COBOL setzt genau an diesem Punkt an
Der Grundgedanke von P3/COBOL ist, bestehende COBOL-Anwendungen nicht vorschnell durch eine vollständige Neuentwicklung zu ersetzen. Stattdessen wird die vorhandene Software als fachliche Grundlage für den Übergang nach Java genutzt.
P3/COBOL ist ein Cross-Compiler, der COBOL in Java-Quellcode übersetzt. Dabei stehen unterschiedliche Wege zur Verfügung: Unternehmen können ihre COBOL-Sourcen beibehalten und Java als Zielumgebung nutzen, COBOL und Java auf Entwicklerebene kombinieren, den Code über die Java Augmented Syntax schrittweise weiterentwickeln oder direkt in Richtung einer künftig in Java gepflegten Anwendung migrieren.
Entscheidend ist dabei nicht allein, dass am Ende Java-Code entsteht. Entscheidend ist, dass die Transformation auf definierten Regeln beruht und nicht jedes Programm bei jeder Übersetzung erneut fachlich interpretiert werden muss.
Das ist der wesentliche Unterschied zu einer rein generativen Herangehensweise. Ein deterministischer Compiler arbeitet unter gleichen Voraussetzungen nach denselben Transformationsregeln. Ein Sprachmodell kann dagegen bei einer erneuten Generierung zu einer anderen Umsetzung gelangen. Das macht KI nicht automatisch schlechter, stellt aber andere Anforderungen an Kontrolle und Qualitätssicherung.
Erst die Logik erhalten, dann gezielt verändern
In vielen Modernisierungsprojekten wird der technische Plattformwechsel mit einer fachlichen und architektonischen Neuentwicklung vermischt. Das kann sinnvoll sein, erhöht aber die Zahl der Veränderungen, die gleichzeitig beherrscht werden müssen.
P3/COBOL ermöglicht eine andere Vorgehensweise. Die bestehende COBOL-Logik kann zunächst in eine Java-basierte Umgebung übertragen werden. Anschließend lässt sich entscheiden, welche Teile unverändert bleiben, welche optimiert werden und wo eine weitergehende Neugestaltung tatsächlich Nutzen bringt.
Ein wichtiger Baustein ist dabei die Java Augmented Syntax, kurz JAS. Sie unterstützt die schrittweise Neuformulierung von COBOL-Regeln in einer Form, die sich gezielter nach Java übertragen lässt. Dadurch muss nicht die gesamte Anwendung auf einmal neu verstanden und umgesetzt werden. Fachliche und technische Änderungen können in überschaubaren Schritten erfolgen.
Gerade bei großen Anwendungen ist das ein erheblicher Vorteil. Die ursprüngliche COBOL-Anwendung bleibt als Referenz verfügbar, während einzelne Bereiche weiterentwickelt und ihre Ergebnisse überprüft werden können.
Warum das für Banken und Versicherungen relevant ist
Nehmen wir eine gewachsene Anwendung zur Berechnung von Versicherungsleistungen. Sie enthält über Jahrzehnte entstandene Regeln, unterschiedliche Vertragsgenerationen und Sonderfälle, die vielleicht nur selten auftreten.
Bei einer vollständigen Neuentwicklung muss dieses Verhalten zunächst verstanden und anschließend erneut implementiert werden. Jede nicht erkannte Regel kann dabei zu einer Abweichung führen. Besonders kritisch sind Fehler, die keinen Programmabbruch verursachen, sondern lediglich in bestimmten Fällen einen falschen Betrag erzeugen.
Eine kontrollierte Transformation verfolgt einen anderen Ansatz. Sie versucht zunächst, das vorhandene Verhalten zu erhalten. Die fachliche Weiterentwicklung erfolgt anschließend gezielt und kann gegen das Bestandssystem geprüft werden.
Natürlich ist auch ein deterministischer Compiler keine Garantie dafür, dass eine komplexe Migration automatisch korrekt ist. Unterschiedliche Laufzeitumgebungen, Datenzugriffe, Schnittstellen und technische Besonderheiten müssen weiterhin untersucht und getestet werden. Reproduzierbarkeit bedeutet nicht automatisch fachliche Gleichheit.
Sie schafft aber eine wichtige Voraussetzung: Wenn eine Transformationsregel angepasst wird, lässt sich nachvollziehen, welche Änderung vorgenommen wurde und wie sie sich auf den betroffenen Code auswirkt. Das ist eine andere Ausgangslage, als wenn umfangreiche Programmteile jedes Mal neu generiert und anschließend erneut bewertet werden müssen.
Und welche Rolle spielt KI dabei?
Aus meiner Sicht wäre es falsch, daraus einen Gegensatz zwischen P3/COBOL und KI zu konstruieren. Beide Ansätze können sich sinnvoll ergänzen.
KI kann helfen, COBOL-Anwendungen zu analysieren, Abhängigkeiten sichtbar zu machen, Geschäftsregeln zu dokumentieren und Testfälle vorzubereiten. Sie kann Entwickler auch dabei unterstützen, geeignete Bereiche für eine spätere Überarbeitung zu identifizieren.
Die eigentliche Transformation kann dort, wo es technisch sinnvoll ist, weiterhin über definierte und reproduzierbare Verfahren erfolgen. Anschließend können KI und erfahrene Entwickler gemeinsam daran arbeiten, die erzeugte Anwendung besser verständlich, wartbar und architektonisch geeigneter zu machen.
Damit wird KI nicht zum Ersatz für eine Modernisierungsmethode, sondern zu einem Werkzeug innerhalb eines kontrollierten Prozesses.
Nicht alles neu machen, sondern das Richtige verändern
Die Fortran-Forschung ist noch ein Proof of Concept und lässt sich nicht unmittelbar auf geschäftskritische COBOL-Anwendungen übertragen. Interessant ist jedoch, dass die Forscher bei einer modernen Zieltechnologie erneut auf strukturierte Compilerverfahren, Semantikerhalt und überprüfbare Ergebnisse setzen.
Genau diese Überlegungen gehören seit Langem zum Konzept von P3/COBOL. Bestehende Software wird nicht als Hindernis betrachtet, das möglichst schnell verschwinden muss, sondern als wertvolle Grundlage, die sich kontrolliert weiterentwickeln lässt.
Das bedeutet nicht, dass jede Anwendung übersetzt werden sollte oder dass eine Neuentwicklung grundsätzlich falsch wäre. Es bedeutet lediglich, dass wir die Entscheidung nicht von der Attraktivität einer neuen Programmiersprache abhängig machen sollten.
Denn bei der Modernisierung geht es nicht darum, möglichst viel COBOL durch möglichst viel Java zu ersetzen. Es geht darum, bewährte Geschäftslogik zu erhalten, technische Abhängigkeiten zu reduzieren und Anwendungen für die kommenden Jahre weiterentwickelbar zu machen.
Vielleicht ist deshalb die wichtigste Frage nicht, wie schnell wir eine Anwendung neu schreiben können, sondern wie viel wir wirklich neu schreiben müssen.