Replatformierung oder Rearchitektur? Wie wählt man den richtigen Modernisierungsweg für Legacy-COBOL?

Zwei Organisationen mit COBOL-Portfolios ähnlicher Größe treffen unterschiedliche Modernisierungsentscheidungen. Die eine Organisation führt eine Replattformierung durch: Sie migriert ihre COBOL-Programme mithilfe von AWS Mainframe Modernization oder einer COBOL-Emulationsschicht in die Cloud-Infrastruktur, wobei der Code erhalten bleibt und der physische Mainframe entfällt. Innerhalb von 18 Monaten senkt sie die Infrastrukturkosten um 40 % und das Programm gilt als Erfolg. Die andere Organisation versucht denselben Ansatz, stößt nach zwölf Monaten an ihre Grenzen und entscheidet sich für eine Neuarchitektur, bei der die wichtigsten Programme als Java-Microservices neu entwickelt werden. Diese Umstellung kostet das Doppelte des ursprünglichen Budgets und dauert drei weitere Jahre.

Gleicher Ausgangspunkt. Radikal unterschiedliche Ergebnisse. Der Unterschied lag nicht in den Tools, den Anbietern oder den Teams. Vielmehr entschied sich die zweite Organisation für eine Replatforming-Lösung für Systeme mit architektonischen Einschränkungen, die die neue Plattform nicht bewältigen konnte: CICS-Transaktionsabhängigkeiten, VSAM-Dateistrukturen und Echtzeitanforderungen, die der replatformierte Code ohne grundlegende Neugestaltung nicht erfüllen konnte. Die Entscheidung fiel, bevor irgendjemand die Systeme ausreichend verstand, um sie richtig zu treffen.

Was jeder Pfad tatsächlich für COBOL bedeutet

Die allgemeinen Definitionen sind bekannt. Entscheidend ist jedoch, was die einzelnen Wege speziell für COBOL-Programme bedeuten, da sich Architektur, Ausführungsmodell und Datenstrukturen von modernen Anwendungen in einer Weise unterscheiden, die direkten Einfluss darauf hat, welcher Weg praktikabel ist.

Replatforming COBOL

Durch die Replatformierung werden COBOL-Programme in eine neue Betriebsumgebung, typischerweise eine Cloud-Infrastruktur, migriert, wobei der Code weitgehend unverändert bleibt. Der COBOL-Code wird auf der neuen Plattform kompiliert und ausgeführt, entweder nativ (mit dem COBOL-Compiler von IBM unter Linux) oder über eine Emulationsschicht, die Mainframe-spezifische Aufrufe (CICS, VSAM, JES) abfängt und in Cloud-native Äquivalente übersetzt.

Was bei einer Replatformierung erhalten bleibt:

• Der COBOL-Quellcode
• Die Logik, die Berechnungen und die Geschäftsregeln des Programms
• Das Batch-Ausführungsmodell (PERFORM-Schleifen, sequentielle Dateiverarbeitung)
• Die Datenstrukturen (Datensatzlayouts, Copybook-Definitionen)
• Die JCL-Jobstruktur (für den neuen Scheduler neu geschrieben, aber logisch äquivalent)

Welche Änderungen ergeben sich durch die Replatforming-Maßnahmen?

• Die physische Infrastruktur (z/OS → Linux in der Cloud)
• Das E/A-Subsystem (VSAM → verwalteter Dateispeicher oder Datenbank, je nach Tool)
• Der Job-Scheduler (JES2/JES3 → AWS Batch, Azure Logic Apps oder gleichwertig)
• Das Kostenmodell (MIPS-basierte Abrechnung → verbrauchsbasierte Cloud-Abrechnung)

Wichtigste Erkenntnis: Eine Replatformierung ist dann angebracht, wenn das Problem in der Plattform selbst, den Kosten für den Betrieb von z/OS, der Infrastrukturabhängigkeit oder dem MIPS-Abrechnungsmodell liegt. Sie ist der falsche Weg, wenn das Problem im Code oder der Architektur liegt.

COBOL-Neuarchitektur

Die Neuarchitektur verändert die grundlegende Systemarchitektur. Die Geschäftslogik bleibt erhalten oder wird aus dem COBOL-Quellcode neu abgeleitet, jedoch in einer neuen Sprache, mit einem neuen Ausführungsmodell und einer neuen Datenschicht implementiert. Das Ergebnis ist ein System, das die Funktionen des COBOL-Systems erfüllt, dessen Struktur sich aber deutlich unterscheidet.

Welche Änderungen ergeben sich durch die Umstrukturierung?

• Die Programmiersprache (COBOL → Java, Python, Go, C#)
• Das Ausführungsmodell (Batchverarbeitung → ereignisgesteuert, Streaming oder API-basiert)
• Die Datenschicht (VSAM-Dateien → relationale Datenbank, NoSQL, Cloud-nativer Speicher)
• Das Transaktionsmodell (CICS-Pseudo-Konversation → RESTful-Zustandslose Dienste)
• Das Integrationsmuster (gemeinsame Datensätze → API-Verträge, Nachrichtenwarteschlangen)

Was bei einer Umgestaltung erhalten bleiben muss:

• Alle Geschäftsregeln, die COBOL implementiert, einschließlich undokumentierter Sonderfälle
• Jede Berechnung, einschließlich der numerischen Genauigkeitseigenschaften der gepackten Dezimalarithmetik
• Jede Datentransformation, einschließlich impliziter Konvertierungen in MOVE-Anweisungen
• Jeder Fehlerzustand, einschließlich der spezifischen Dateistatuscodes und Abbruchverhalten, von denen nachgelagerte Systeme abhängen können

Achtung: Der häufigste Fehler bei Systemumstrukturierungen besteht darin, festzustellen, dass der COBOL-Code Geschäftsregeln enthält, die nirgendwo anders dokumentiert wurden. Das neue System verhält sich in bestimmten Sonderfällen anders als das alte, nicht aufgrund eines Implementierungsfehlers, sondern weil die Spezifikation unvollständig war. Die Geschäftslogik muss daher vor Beginn der Umstrukturierung aus dem COBOL-Quellcode extrahiert und dokumentiert werden.

Die COBOL-spezifischen Faktoren, die diese Entscheidung beeinflussen

Generische Modernisierungsframeworks betrachten Replatforming und Re-Architektur primär als Entscheidungen, die von Kosten, Zeitrahmen und Risiko abhängen. Bei COBOL hingegen beeinflussen mehrere sprachspezifische technische Faktoren sowie die Laufzeitumgebung die Entscheidung maßgeblich in die eine oder andere Richtung.

CICS-Transaktionsabhängigkeiten

CICS (Customer Information Control System) ist die Transaktionsverarbeitungs-Middleware, die viele COBOL-Programme für interaktive Arbeitslasten nutzen. Ein COBOL-Programm, das EXEC CICS-Aufrufe tätigt, ist implizit vom CICS-Transaktionsserver für Bildschirmverwaltung, Terminalkommunikation, Aufgabenverteilung und Programmsteuerung abhängig.

Auswirkungen der Plattformumstellung: Tools wie die Micro Focus CICS-Emulation, OpenFrame und einige AWS Mainframe Modernization-Funktionen emulieren die CICS-Semantik. Bei standardkonformer und korrekter CICS-Nutzung kann die Emulation funktionieren. Nutzt das Programm jedoch CICS-Interna, Kommarea-Manipulation, Synchronisationspunktsteuerung oder Task-Speicherung, verschlechtert sich die Emulationsgenauigkeit.

Umstrukturierung der Architektur: Bei einem CICS-Programm, das in eine REST-API umgewandelt wird, muss das pseudo-konversationelle Transaktionsmodell als zustandslose Interaktion neu gestaltet werden. Dies ist eine Architekturänderung, keine Codeübersetzung.

Signal für einen Rearchitekten: Intensive Nutzung von CICS mit komplexer Kommarea-Verwaltung, Backend-Transaktionsverkettung oder Synchronisationspunktlogik.

VSAM-Dateiarchitektur

VSAM (Virtual Storage Access Method) ist das indizierte Dateisystem, das von den meisten COBOL-Produktionsprogrammen verwendet wird. VSAM-Dateien weisen spezifische Zugriffsmuster auf – KSDS (keyed sequenzial), ESDS (entry-sequenzial) und RRDS (relative record) –, für die es keine direkten Entsprechungen in Cloud-nativen Speichersystemen gibt.

Auswirkungen der Plattformumstellung: Emulationsschichten übersetzen VSAM-Lese- und Schreibvorgänge in zugrundeliegende Datei- oder Datenbankoperationen. Für einfache sequentielle oder schlüsselbasierte Zugriffe funktioniert dies. Bei komplexen Zugriffen mit alternativen Schlüsseln, VSAM-Clustern, die von mehreren Programmen gemeinsam genutzt werden, oder leistungskritischen Zufallszugriffsmustern führt die Emulation jedoch zu erhöhter Latenz und Komplexität.

Auswirkungen auf die Neuarchitektur: Der Ersatz von VSAM durch eine relationale Datenbank erfordert die Zuordnung von Datensatzlayouts zu Tabellenschemata, die Behandlung der impliziten Datentypkonvertierungen und das Umschreiben jedes Dateizugriffs mittels SQL oder eines ORM.

Signale, die zu einer Neuarchitektur drängen: VSAM-Dateien, die von vielen Programmen gemeinsam genutzt werden, alternative Indexzugriffsmuster oder Echtzeit-Leistungsanforderungen, die durch Emulation nicht erfüllt werden können.

Batch- vs. Echtzeit-Anforderungen

COBOL-Batchprogramme sind darauf ausgelegt, große Datenmengen sequenziell in festgelegten Zeitfenstern zu verarbeiten. Viele Systeme im Bank-, Versicherungs- und Regierungssektor führen nach wie vor nächtliche Batch-Jobs durch, die Millionen von Transaktionen verarbeiten, Berichte erstellen und Stammdaten aktualisieren.

Auswirkungen der Plattformumstellung: Die Batch-Semantik lässt sich gut auf die Batch-Ausführung in der Cloud (AWS Batch, Azure Batch) übertragen. Das sequentielle Verarbeitungsmodell bleibt auch nach dem Plattformwechsel erhalten. Wenn es lediglich darum geht, denselben Batch-Job auf einer kostengünstigeren Infrastruktur auszuführen, erfüllt die Plattformumstellung dieses Ziel direkt.

Konsequenz für die Umstrukturierung der Architektur: Wenn sich die Geschäftsanforderungen geändert haben – von der Verarbeitung über Nacht zu nahezu Echtzeit, vom dateibasierten Datenaustausch zur API-Integration, von monolithischen Batch-Läufen zu individuell ausgelösten Microservices –, reicht eine Replatformierung nicht aus, um die neuen Anforderungen zu erfüllen. Die Architektur muss angepasst werden.

Signal für einen Rearchitekten: Anforderungen der Stakeholder an Echtzeitverarbeitung, API-basierte Integration, ereignisgesteuerte Architektur oder Reaktionszeiten im Subsekundenbereich, die Batch-Semantik nicht bieten kann.

Eingebettete Geschäftslogik ohne externe Spezifikation

Dies ist der am meisten unterschätzte COBOL-spezifische Faktor. Zu den Hauptrisiken zählen der Verlust kritischer Geschäftsregeln in jahrzehntealtem Code und die unzureichende Dokumentation des Systemverhaltens. COBOL-Programme enthalten oft die einzige erhaltene Spezifikation einer Geschäftsregel. Die Vorschrift, die eine bestimmte Berechnung erforderte, stammt aus dem Jahr 1983. Der zuständige Business-Analyst ging 2001 in den Ruhestand. Der COBOL-Code ist nicht nur die Implementierung, sondern auch die Dokumentation.

Folge einer Replatformierung: Die Geschäftsregeln bleiben unverändert erhalten, da der Code beibehalten wird. Dies ist eines der stärksten Argumente für eine Replatformierung.

Konsequenz für den Rearchitekten: Die Geschäftsregeln müssen vor der Neuimplementierung aus dem COBOL-Quellcode extrahiert werden. <cite index=”28-1″>Undokumentierter, eng gekoppelter Code vervielfacht den Aufwand in jeder Phase.</cite> Ist diese Extraktion unvollständig, weist das neue System eine andere Spezifikation als das alte auf, und diese Unterschiede treten im Produktivbetrieb zutage.

Ein Entscheidungsrahmen: Acht Fragen

Bevor man sich für einen Weg entscheidet, liefern diese acht Fragen die nötigen Erkenntnisse, um die Entscheidung mit Zuversicht und nicht mit Annahmen zu treffen.

1. Was ist der Hauptgrund für diese Modernisierung?

• Infrastrukturkosten → Replatformierung ausreichend
• Plattformabhängigkeit (z/OS) → Replatformierung ausreichend
• Echtzeitanforderungen → Umstrukturierung erforderlich
• Integrationsanforderungen (API) → Umstrukturierung wahrscheinlich erforderlich
• Wartbarkeit / Verfügbarkeit von Fachkräften → Umstrukturierung oder Refactoring

2. Wie hoch ist die CICS-Kopplung? Listen Sie alle EXEC CICS-Aufrufe auf. Zählen Sie Programme mit mehr als zwanzig verschiedenen CICS-Befehlen. Programme mit starker CICS-Kopplung eignen sich schlecht für eine Replatformierung, wenn die Emulationsgenauigkeit unsicher ist.

3. Welche Zugriffsmuster gibt es bei VSAM-Dateien? Identifizieren Sie Programme, die mit alternativen Schlüsseln, gemeinsam genutzten Clustern oder leistungskritischem Direktzugriff auf VSAM-Dateien zugreifen. Dies sind Indikatoren für ein Replatforming-Risiko.

4. Wurde die Geschäftslogik extern dokumentiert? Wenn der COBOL-Quellcode die einzige maßgebliche Spezifikation ist, erfordert die Neuarchitektur die Extraktion der Geschäftslogik als Voraussetzung und nicht als parallele Arbeitslast.

5. Wie hoch ist die Toleranz des Batch-Verarbeitungsfensters? Benötigt das Unternehmen dasselbe Batch-Verarbeitungsmodell zu geringeren Kosten, ist ein Plattformwechsel erforderlich. Benötigt das Unternehmen dieselbe Verarbeitung in Echtzeit, ist eine Neuarchitektur notwendig.

6. Wie komplex sind die Abhängigkeiten? Ein Programm mit fünfzig nachgelagerten Abhängigkeiten (Datensätzen, sogenannten Unterprogrammen und JCL-Aufrufern) birgt ein höheres Risiko für eine Neuarchitektur als ein eigenständiges Hilfsprogramm. Die Abhängigkeitsstruktur bestimmt die Migrationsreihenfolge und den Testumfang.

7. Welcher Anteil des Codes ist ungenutzt? Wenn ungenutzter Code vor der Konvertierung ausgeschlossen wird, reduziert sich der Aufwand in beiden Fällen. Bei neu strukturierten Programmen wird nicht ausgeschlossener ungenutzter Code vollständig konvertiert und anschließend verworfen.

8. Wie ist die Komplexitätsverteilung? Eine zyklomatische Komplexität von über 50 pro Programm oder mehr als zwanzig enthaltene Copybooks deuten auf Programme hin, die einen hohen Aufwand für die Neuarchitektur und ein hohes Risiko für eine Plattformumstellung erfordern. Diese Programme benötigen individuelle Aufmerksamkeit anstelle einer massenhaften Pfadzuweisung.

Anwendung des Frameworks: Vier COBOL-Systemprofile

Profil	Eigenschaften	Empfohlener Pfad	Begründung
Stabiles Batch-Dienstprogramm	Sequenzielle Datei-E/A, kein CICS, gut dokumentierte Logik, geringe Komplexität	Plattform neu	Die Plattformkosten sind das Problem; der Code ist nicht die Einschränkung.
CICS-intensive Online-Transaktion	Intensive Nutzung von EXEC CICS, Kommarea-Abhängigkeiten, pseudo-konversationelles Modell	Umgestalten	Das Risiko einer CICS-Emulation ist hoch; Echtzeitanforderungen sind wahrscheinlich.
VSAM Master File Processor	Komplexe VSAM-Zugriffsmuster, die von vielen Programmen gemeinsam genutzt werden, hohes Lesevolumen	Prüfen Sie zunächst die Genauigkeit der Emulation; wechseln Sie zur neuen Plattform, falls die Emulation weiterhin Probleme bereitet.	Die VSAM-Emulation ist die Entscheidungsvariable
Geschäftslogik Treasury	Undokumentierte Regeln, keine externe Spezifikation, hohe regulatorische Bedeutung	Zuerst die Logik extrahieren, dann auswählen	Das Risiko einer Umstrukturierung ist ohne vorherige Extraktion der Geschäftslogik inakzeptabel.

Wichtigste Erkenntnis: <cite index=”30-1″>In der Praxis werden bei großen Systemen verschiedene Ansätze kombiniert: Stabile Komponenten werden auf eine neue Plattform umgestellt, schwer wartbarer Code wird refaktoriert, die wenigen Systeme mit neuen Funktionen werden neu geschrieben und nicht mehr genutzte Systeme werden stillgelegt.</cite> Die Entscheidung wird nicht auf Portfolioebene, sondern auf Arbeitslastebene getroffen und individuell für jedes Programm oder jede Programmgruppe auf Grundlage der vorliegenden Daten angewendet.

Der hybride Ansatz: Zuerst die Plattform neu gestalten, dann gegebenenfalls die Architektur überarbeiten

Eine praktische Regel: Um den Schaden schnell zu stoppen, sollte man auf eine neue Plattform umsteigen oder die Systeme, die echte Wettbewerbsvorteile bieten, überarbeiten oder neu strukturieren.

Für die meisten Organisationen mit großen COBOL-Portfolios ist die praktische Reihenfolge:

Phase 1: Umstellung der geeigneten Programme auf eine neue Plattform. Programme ohne CICS, mit einfacher sequenzieller E/A, dokumentierter Logik und geringer Komplexität können mit überschaubarem Aufwand und Risiko umgestellt werden. Dies führt zu einer schnellen Senkung der Infrastrukturkosten und stärkt das Vertrauen der Organisation.

Phase 2: Bewertung komplexer Programme. Programme mit CICS-Anbindung, komplexen VSAM-Mustern oder undokumentierter Geschäftslogik erfordern eine individuelle Analyse, bevor ein Lösungsweg gewählt wird. Hierbei bestimmen die Extraktion der Geschäftslogik und die Strukturanalyse, ob eine Umstrukturierung notwendig ist und welchen Umfang diese hätte.

Phase 3: Umstrukturierung der Programme mit architektonischen Hindernissen. Programme, die die Geschäftsanforderungen der replatformierten Infrastruktur, Echtzeitanforderungen, API-Integration oder ereignisgesteuerte Verarbeitung nicht erfüllen können, werden mithilfe des Strangler-Fig-Musters umstrukturiert: Der neue Dienst wird parallel zum replatformierten Programm aufgebaut, der Datenverkehr wird schrittweise zur neuen Implementierung umgeleitet, sobald jede Komponente validiert ist, und das alte Programm wird außer Betrieb genommen, sobald der gesamte Datenverkehr migriert ist.

Phase 4, Außerbetriebnahme von veraltetem Code. Programme, die während der Strukturanalyse als veraltet identifiziert wurden, werden von beiden Pfaden ausgeschlossen und stillgelegt, wodurch die laufenden Wartungskosten ohne Umstellungsaufwand reduziert werden.

---

Was die Analyse vor jeder Entscheidung ergeben muss

Das oben beschriebene Entscheidungsmodell liefert bessere Ergebnisse, wenn die Eingangsdaten auf Fakten und nicht auf Schätzungen beruhen. Die Strukturanalyse, die diese Eingangsdaten liefert, erfordert das Parsen des tatsächlichen COBOL-Quellcodes, anstatt sich auf Dokumentation oder Entwicklerwissen zu stützen.

Was die Analyse für jedes Programm feststellen muss:

Eine vollständige Programmübersicht, einschließlich solcher Programme, die nicht dokumentiert sind. In großen COBOL-Umgebungen übersteigt der Anteil undokumentierter Programme oft 20 %. Ein Abhängigkeitsdiagramm zeigt, welche Programme welche anderen aufrufen, welche Datensätze gemeinsam genutzt werden und welche JCL-Jobs welche Programme aufrufen. Eine CICS-Befehlsübersicht für jedes Programm mit Anzahl, Typen und Komplexität der Aufrufe. Eine VSAM-Zugriffsmusteranalyse zeigt, welche Zugriffsmethoden verwendet werden, welche Dateien programmübergreifend genutzt werden und welche Dateien alternative Indizes besitzen. Eine Verteilung der zyklomatischen Komplexität zeigt, welche Programme strukturell einfach sind und welche ein hohes Konvertierungsrisiko darstellen. Die Identifizierung von totem Code zeigt, welche Programme und Abschnitte keine eingehenden Ausführungspfade haben. Die Extraktion der Geschäftslogik zeigt, welche Regeln jedes Programm implementiert, und ermöglicht die Validierung der Ausgabe beider Pfade.

Ohne diese Bestandsaufnahme wird die Entscheidung über den Migrationspfad auf Basis unvollständiger Informationen getroffen. Programme werden aufgrund von Annahmen, die sich bei der Emulation als falsch erweisen, einer Replatformierung zugeordnet. Diese Annahmen decken architektonische Einschränkungen auf, die während der Planung nicht erkennbar waren.

Wie SMART TS XL Erstellt die vorprozessualen Beweise

SMART TS XL Modernisierung des Altbestands Die Analyse automatisiert die oben beschriebene Strukturinventur, indem sie jedes COBOL-Programm, Copybook, JCL-Job und jede VSAM-Dateireferenz gleichzeitig analysiert, um das einheitliche Abhängigkeitsmodell zu erstellen, das die Pfadentscheidung evidenzbasiert macht.

Die Abbildung der Anwendungsabhängigkeiten erzeugt den programmübergreifenden Aufrufgraphen und die Datensatzfreigabekarte, die die Abhängigkeitskomplexität bestimmt, den Faktor, der sich am direktesten sowohl auf das Risiko der Replatform-Emulation als auch auf den Umfang und die Reihenfolge der Rearchitektur auswirkt.

Die statische Codeanalyse liefert Komplexitätsmetriken, CICS-Aufrufinventare und Informationen zu ungenutztem Code für jedes Programm im Portfolio. Programme, die die Schwelle der zyklomatischen Komplexität überschreiten und stark an CICS gekoppelt sind, werden automatisch als Kandidaten für eine Überarbeitung oder Bewertung identifiziert, anstatt massenhaft einer Replatformierung zugewiesen zu werden.

Die JCL-Erweiterung löst symbolische Parameter auf und erstellt die vollständige Abhängigkeitskette der Batch-Ausführung, welche JCL-Jobs welche Programme in welcher Reihenfolge mit welchen Datensätzen aufrufen. Dadurch wird der operative Kontext bereitgestellt, der bestimmt, wie sich die Ausgabe beider Pfade verhalten muss, um den Batch-Zeitplan zu erfüllen.

Die Wirkungsanalyse legt den Umfang jedes Pfades vor Programmbeginn konkret fest: Für jedes zur Umstrukturierung ausgewählte Programm listet die Wirkungsanalyse alle abhängigen Programme auf, die aktualisiert, erneut getestet oder mit der umstrukturierten Komponente abgestimmt werden müssen. Bei Kandidaten für eine Plattformreorganisation identifiziert dieselbe Analyse die gemeinsam genutzten Datensätze und Unterprogramme, die programmübergreifende Abhängigkeiten erzeugen, welche einheitlich behandelt werden müssen.

Die unternehmensweite Suche ermöglicht die Abfrage des gesamten Inventars im gesamten Programm: Finden Sie jedes Programm, das einen bestimmten CICS-Befehl verwendet, jedes Programm, das auf einen bestimmten VSAM-Cluster zugreift, jedes Copybook, das eine bestimmte Datenstruktur definiert, in Sekundenschnelle, über Millionen von COBOL-Zeilen hinweg.

Die Organisationen, die diese Entscheidung richtig treffen, sind diejenigen, die sie auf der Grundlage struktureller Erkenntnisse und nicht auf der Grundlage von Annahmen aus dem Projektplan treffen. Die strukturellen Erkenntnisse sind das, was SMART TS XL produziert.