Wartung von Legacy-Systemen: Fortran, COBOL und andere klassische Technologien

Viele der Systeme, die unsere Welt im Stillen am Laufen halten, wurden lange geschrieben, bevor die heutigen Entwickler in die Branche kamen. Fortran, geboren 1957, bleibt das Rückgrat der wissenschaftlichen und ingenieurtechnischen Berechnungen — Klimamodelle, numerische Strömungsmechanik, Nuklearsimulationen und seismische Verarbeitung sind alle davon abhängig. COBOL, fast genauso alt, verarbeitet einen bemerkenswerten Anteil der globalen Banktransaktionen, Behördenakten, Lohnabrechnungen und Versicherungsansprüche. Darüber hinaus läuft PL/I noch immer in Mainframe-Umgebungen, Pascal und Delphi treiben Kassensysteme und Industrieautomation an, klassisches Visual Basic 6 verharrt in unzähligen internen Werkzeugen, und handgeschriebener Assembler steuert weiterhin eingebettete Geräte, die seit Jahrzehnten im Einsatz sind.

Dies sind keine akademischen Kuriositäten. Branchenschätzungen beziffern die globale COBOL-Codebasis auf weit über 200 Milliarden Zeilen — der Großteil läuft jede Nacht unbeaufsichtigt in der Produktion. Voyager 1 und 2 — derzeit die am weitesten entfernten von Menschen gemachten Objekte im Universum — werden noch immer von Software gesteuert, die größtenteils in den 1970er Jahren in Fortran und Assembler geschrieben wurde. Das US-Finanzamt IRS, die Social Security Administration und die meisten großen Flugreservierungssysteme stützen sich weiterhin auf Code aus der Mainframe-Ära. Diese Systeme sind die Infrastruktur des modernen Lebens.

Warum Legacy-Systeme überleben

Die zynische Antwort auf "warum sind sie noch da?" lautet "weil niemand wagt, sie zu ersetzen". Die realistische Antwort ist nuancierter.

Eine über dreißig Jahre verfeinerte Fortran-Simulation in Luft- und Raumfahrt oder Klimamodellierung trägt eine enorme Menge implizites Wissen — jeder numerische Grenzfall, jede Umgehung für eine Eigenheit des ursprünglichen Solvers, jede gegen physikalische Messungen validierte Anpassung. Ein COBOL-Batch-Job, der jede Nacht das Hauptbuch einer Bank abschließt, wurde über Jahrzehnte hinweg ein Grenzfall nach dem anderen korrigiert — jede Korrektur spiegelt einen realen Vorfall wider. Den Code wegzuwerfen bedeutet, dieses institutionelle Wissen wegzuwerfen. Ein Wiederaufbau von Grund auf ist selten billiger, schneller oder sicherer als die Wartung dessen, was bereits funktioniert.

Berühmte gescheiterte Neuschreibungen bestätigen diese Lektion. Mehrere große Banken, staatliche Steuerbehörden und Fluggesellschaften haben gemeinsam Milliarden in Modernisierungsprogramme investiert, die letztendlich reduziert oder aufgegeben wurden. Die mahnenden Geschichten folgen ungefähr demselben Bogen: die eingebettete Geschäftslogik unterschätzen, auf unerwartete Integrationsbeschränkungen stoßen, das Budget oder den politischen Willen erschöpfen und doch wieder zur Wartung des Legacy-Systems zurückkehren.

Die Realität der Wartung

Teams, die Legacy-Stacks unterstützen, stoßen typischerweise auf eine wiederkehrende Reihe von Hindernissen.

Spezialisten sind rar und werden seltener. Die meisten Universitäten haben vor Jahrzehnten aufgehört, Fortran 77 oder COBOL zu lehren. Die verbleibenden Experten sind oft nur noch wenige Jahre vom Ruhestand entfernt, und der Nachschub an Ersatz ist dünn. Wenn ein erfahrener Ingenieur geht, nimmt er Kontext mit, den kein Dokument festhält.

Toolchains zerfallen. Originalcompiler, Build-Umgebungen und Debugger laufen möglicherweise nur auf Betriebssystemen, die selbst nicht mehr unterstützt werden. Eine typische Legacy-Build-Pipeline hängt von einer bestimmten Compiler-Version eines Anbieters ab, der nicht mehr existiert, und läuft auf einer Server-Version, die seit Jahren keine Sicherheitspatches mehr erhält.

Tests fehlen meistens. Die meisten Legacy-Systeme stammen aus einer Zeit, bevor automatisiertes Testen zum Standard wurde. Qualitätssicherung erfolgte manuell, oft durch Domänenexperten, die wussten, welche Zahlen in welchem Bericht erscheinen sollten. Sobald diese Personen in den Ruhestand gehen, wird das System effektiv zu einer Black Box, die niemand mit gutem Gewissen ändern kann.

Stammeswissen dominiert. Kritische Annahmen leben in den Köpfen einiger weniger langjähriger Ingenieure und nicht in irgendeinem Dokument. "Führe niemals den Monatsendabschluss am ersten Werktag nach einem Schaltjahr aus" ist die Art von Regel, die nirgendwo außer in jemandes Erinnerung existiert.

Integration ist ungelenk. Moderne Systeme müssen mit diesen Stacks über die verfügbaren Schnittstellen kommunizieren — Flatfiles, Datensätze fester Breite, FTP-Drops um drei Uhr morgens, Screen-Scraping über 3270-Terminalemulatoren oder herstellerspezifische binäre Protokolle. Jede Schnittstelle ist eine Quelle der Brüchigkeit.

Datenformate sind nicht das, was Sie denken. EBCDIC statt ASCII, Packed Decimal statt nativer Ganzzahlen, COBOL-Copybooks, die mehrere Datensatzlayouts auf dieselben Bytes legen, Fortran-COMMON-Blöcke, die stillschweigend Speicher zwischen Subroutinen teilen, gemischt-endian Binärdumps von alten Unix-Workstations — ein "einfacher" Datenexport ist selten einfach, und ein einziges falsch interpretiertes Byte kann Millionen von Datensätzen beschädigen, bevor jemand es bemerkt.

Ein praktischer Leitfaden

Es gibt keine einzig richtige Antwort, aber einige Ansätze funktionieren in der Praxis durchgängig.

1. Machen Sie das System beobachtbar, bevor Sie etwas ändern. Fügen Sie Logging, Monitoring und reproduzierbare Builds hinzu. Erfassen Sie das aktuelle Verhalten in Charakterisierungstests — Tests, die tatsächliche Ausgaben für bekannte Eingaben aufzeichnen, unabhängig davon, ob dieses Verhalten formal korrekt ist. Dies ist die Umkehrung des klassischen TDD: In Legacy-Systemen behandeln Sie die bestehende Implementierung als Orakel und refaktorieren erst dann unter diesem Sicherheitsnetz. Ohne diesen Schritt ist jede Änderung ein Ratespiel.

2. Stabilisieren Sie die Toolchain. Bringen Sie den Build in einen Container oder eine virtuelle Maschine, die Sie kontrollieren. Pinnen Sie Compiler-Versionen. Verschieben Sie den Quellcode in eine moderne Versionskontrolle, falls noch nicht geschehen. Stellen Sie sicher, dass ein sauberer Checkout auf einer frisch bereitgestellten Maschine ein funktionierendes Binary produzieren kann — ohne das ist das System nur einen Festplattenausfall vom Verlust entfernt. Open-Source-Ersatz wie GnuCOBOL, GFortran oder Free Pascal kann manchmal ausgemusterte kommerzielle Compiler ersetzen, aber nur nach sorgfältiger Äquivalenzprüfung.

3. Umhüllen, nicht ersetzen. Legen Sie den Legacy-Kern über eine schlanke moderne API offen — REST, gRPC oder eine Nachrichtenwarteschlange — damit neue Funktionalität in modernen Sprachen darum herum gebaut werden kann. Der Wrapper fungiert als Anti-Corruption Layer, der zwischen dem Legacy-Datenmodell und dem modernen übersetzt. Dies ist die Grundlage des Strangler-Fig-Musters: Sie migrieren Stück für Stück und stellen Teile des alten Systems erst außer Betrieb, nachdem der Ersatz in der Produktion validiert wurde.

4. Dokumentieren Sie aggressiv, besonders das Warum. Quellcode beantwortet, was das System tut. Entscheidungen, Kompromisse und historische Vorfälle erzählen dem nächsten Ingenieur, warum es das auf diese Weise tut — und genau dieser Kontext verschwindet, wenn erfahrene Mitarbeiter gehen. Architecture Decision Records, Runbooks für jede wiederkehrende operative Aufgabe und kurze erzählte Durchgänge durch komplexe Module zahlen sich vielfach aus.

5. Paaren Sie scheidende Experten mit der nächsten Generation. Behandeln Sie Personalbesetzung als strategisches Risiko, nicht als HR-Angelegenheit. Paaren Sie Senioren mit Junioren bei echter Wartungsarbeit, nicht bei Übungen. Lassen Sie den Senior seine Argumentation laut artikulieren. Zeichnen Sie diese Sitzungen auf, wenn Sie können. Das Ziel: die teuerste Form organisatorischen Wissens — was im Kopf einer Person steckt — in die billigste umzuwandeln: das, was niedergeschrieben ist.

6. Modernisieren Sie zuerst die Ränder. Der riskanteste Teil eines Legacy-Systems ist seine Kerngeschäftslogik. Die am wenigsten riskanten Teile sind in der Regel die Eingabe-/Ausgaberänder — Dateiimporte, Berichtserstellung, Benutzeroberflächen, Integrationen. Beginnen Sie dort. Ersetzen Sie die Greenscreen-Oberfläche durch ein modernes Web-Frontend. Wandeln Sie Flatfile-Importe in ereignisgesteuerte Pipelines um. Jede erfolgreiche Randablösung baut organisatorisches Vertrauen auf und beseitigt eine weitere Einschränkung, ohne den unersetzlichen Kern zu berühren.

7. Planen Sie einen anständigen Ausstieg, kein heroisches Neuschreiben. Wenn das System ausgemustert werden soll, tun Sie es in einem mehrjährigen Horizont mit klaren Ausstiegsrampen. Identifizieren Sie Geschäftsprozesse, die auf eine moderne Plattform verlagert werden können. Identifizieren Sie diejenigen, die das Legacy-System wirklich erfordern. Reduzieren Sie den Umfang, bis das Verbleibende klein genug ist, um sicher neu geschrieben zu werden — oder um auf unbestimmte Zeit als isolierte Komponente gewartet zu werden.

Daten- und Integrationsfallen, die hervorzuheben sind

Die meisten Modernisierungsprojekte unterschätzen die Datenschicht. Einige spezifische Fallen tauchen immer wieder auf.

Diskrepanzen bei Zeichenkodierungen sind stille Killer. EBCDIC und ASCII sortieren unterschiedlich, sodass eine Sortierung, die auf dem Mainframe korrekt funktionierte, subtil falsche Ergebnisse liefert, sobald die Daten auf eine Linux-Maschine kopiert werden — und der Fehler tritt möglicherweise erst Monate später auf, wenn ein Kunde eine Beschwerde meldet. Numerische Formate sind ebenso heimtückisch: Packed Decimal in COBOL speichert zwei Ziffern pro Byte und ist von keiner modernen Sprache ohne explizite Konvertierung direkt interpretierbar. Fortran-Code, der COMMON-Blöcke verwendet, teilt Speicherbereiche zwischen Subroutinen auf eine Weise, die für Werkzeuge der statischen Analyse unsichtbar ist — die Refaktorisierung solchen Codes ohne Verständnis des gemeinsamen Layouts ist ein garantierter Weg, nichtdeterministische Fehler einzuführen.

Wenn Sie sich mit solchen Systemen integrieren, behandeln Sie jede Schnittstelle als nicht vertrauenswürdig, selbst wenn sie zwanzig Jahre lang "stabil" war. Fügen Sie Schemavalidierung an der Grenze hinzu. Loggen Sie jeden Datensatz, der durchfällt. Gehen Sie niemals davon aus, dass das Feld am Byte-Offset 47 das ist, was die Dokumentation sagt — überprüfen Sie es anhand von Produktionsdaten.

Die wirtschaftliche Argumentation

Die Wartung eines Legacy-Systems ist selten glamourös, aber oft die wirtschaftlich vernünftigste Wahl. Ein erfolgreiches Neuschreiben ist teuer und riskant; ein gescheitertes Neuschreiben ist katastrophal — manchmal existenziell so für die Organisation. Disziplinierte Wartung in Verbindung mit gradueller Modernisierung an den Rändern liefert in der Regel mehr Wert pro Euro als ein Big-Bang-Rewrite und hält die Lichter in der Produktion an, während längerfristige Entscheidungen getroffen werden.

Die richtige Frage lautet selten "neu schreiben oder warten?". Sie lautet: "Welche Teile dieses Systems müssen sich in den nächsten drei Jahren tatsächlich ändern, und was ist der billigste Weg zu diesem Ergebnis, der die Produktion nicht gefährdet?". So formuliert, ist Modernisierung keine binäre Entscheidung mehr, sondern wird zu einem fortlaufenden Portfolio kleiner, umkehrbarer Wetten.

Schluss

Die in Fortran, COBOL und ihren Zeitgenossen geschriebenen Systeme sind keine Relikte. Sie sind funktionierende Infrastruktur, und in vielen Fällen erledigen sie ihre Arbeit besser als alles, was zu ihrer Ablösung vorgeschlagen wurde. Sie mit derselben Sorgfalt und Disziplin zu behandeln, die Sie jedem anderen Produktionssystem zugestehen würden — Beobachtbarkeit, Tests, Versionskontrolle, Dokumentation, Nachfolgeplanung — ist genau das, was sie das nächste Jahrzehnt am Laufen hält.

Das Ziel ist nicht, die Vergangenheit um ihrer selbst willen zu bewahren. Es ist, dem Unternehmen die Freiheit zu geben, seinen nächsten Schritt zu seinen eigenen Bedingungen zu wählen, anstatt zu einem panischen Neuschreiben gezwungen zu werden, wenn die letzte Person, die das System verstand, endlich zur Tür hinausgeht.