In vielen Banken, Versicherungen und Verwaltungen läuft das wichtigste System auf COBOL – und niemand kann es mehr vollständig erklären. Die Programme stammen aus den Siebzigern oder Achtzigern, sie berechnen Konten, Tarife, Fristen, und sie tun das verlässlich. Aber die Menschen, die sie gebaut haben, sind in Rente, und eine aktuelle Dokumentation existiert nicht. Das Wissen steckt nur noch im Code.
Bevor man über irgendeine Zukunft eines solchen Systems nachdenkt, muss man es wieder verstehen. Das nennt man Kartierung. So geht das.
Zuerst die wichtige Klarstellung
Eine COBOL-Migration ist ein eigenes, schwergewichtiges Vorhaben mit eigenen Werkzeugen und Spezialisten. Wir versprechen das bewusst nicht als schnelle Komplettleistung. Was hier beschrieben wird, ist die Vorarbeit, die vor jeder Entscheidung steht – egal, ob am Ende eine Modernisierung, ein Audit oder der bewusste Weiterbetrieb steht. Genau diese Bestandsaufnahme bieten wir an, und nur sie.
Warum COBOL-Systeme so schwer durchschaubar sind
Das Problem ist selten der COBOL-Code selbst. COBOL ist erstaunlich gut lesbar, fast wie ein englischer Satz. Das Problem ist die Menge und die Verflechtung. Ein gewachsenes System umfasst oft hunderte oder tausende Programme, die sich gegenseitig aufrufen, gesteuert über JCL, mit Daten in VSAM-Dateien oder hierarchischen Datenbanken. Niemand hält das ganze Geflecht im Kopf.
Dazu kommen Jahrzehnte an Änderungen, die niemand dokumentiert hat. Jede Anpassung an ein neues Gesetz, jeder Sonderfall für einen Großkunden – eingebaut und vergessen. Das System weiß mehr über das Geschäft als jeder lebende Mitarbeiter.
Schritt 1: Den Bestand erfassen
Kartierung beginnt mit einer Inventur. Welche Programme gibt es überhaupt, welche Copybooks, welche JCL-Jobs, welche Datenbestände? Das klingt banal, ist aber oft schon eine Überraschung – nicht selten finden sich Programme, von denen niemand mehr wusste, dass sie laufen, und andere, die seit Jahren tot im System liegen.
Schritt 2: Die Aufrufkette nachzeichnen
Als Nächstes geht es um die Beziehungen. Welches Programm ruft welches auf, welcher Job startet welche Kette, welche Daten wandern wohin? Daraus entsteht die eigentliche Landkarte: eine Darstellung, die zeigt, wie das System zusammenhängt. Erst sie macht sichtbar, was zentral ist und was Randbezirk – und wo ein Eingriff besonders riskant wäre.
Schritt 3: Die Geschäftslogik freilegen
Das ist der wertvollste Teil. In den Programmen stecken die Regeln, nach denen das Geschäft wirklich funktioniert: wie ein Zins berechnet wird, wann eine Frist greift, welche Ausnahme bei welchem Fall gilt. Diese Regeln werden aus dem Code herausgelesen und explizit gemacht – in verständlicher Sprache, nicht in COBOL. Damit wird das Wissen, das bisher an verschwindenden Personen hing, wieder eigenständig nutzbar.
Schritt 4: Risiken benennen
Zum Schluss die ehrliche Bewertung. Welche Programme sind kritisch, wo droht beim Ausfall der größte Schaden, wie stark hängt der Betrieb an einzelnen Personen? Diese Risikobewertung ist oft der Grund, warum die Kartierung überhaupt in Auftrag gegeben wird – sie macht aus einem diffusen Unbehagen eine konkrete, handhabbare Liste.
Was am Ende herauskommt
Eine Dokumentation, die das System wieder prüfbar und entscheidbar macht. Sie dient drei Zwecken: einem Audit eine belastbare Grundlage geben, eine spätere Modernisierung durch einen spezialisierten Dienstleister vorbereiten, oder die bewusste Entscheidung für den Weiterbetrieb absichern. In jedem Fall ist das Wissen gerettet, das sonst mit der nächsten Pensionierung verschwunden wäre.
Mehr dazu auf den Seiten zur Legacy-Analyse & Dokumentation und zur COBOL-Bestandsanalyse.
Der erste Schritt
Auch für die reine Analyse ist das Code-Assessment der Einstieg. Wir schauen in das System und sagen Ihnen, wie eine Kartierung für Ihren Bestand aussehen würde.
Häufige Fragen
Migrieren Sie unser COBOL danach auch? Nein. Wir liefern ausschließlich Analyse und Dokumentation. Diese Klarheit ist der Grund, warum die Ergebnisse belastbar sind.
Was nützt die Kartierung, wenn keine Migration folgt? Sehr viel: Sie sichern kritisches Wissen, bestehen Audits leichter und verringern die Abhängigkeit von einzelnen Personen – unabhängig davon, was Sie danach entscheiden.
Wir haben gar keine Dokumentation. Geht das trotzdem? Das ist der Regelfall und genau der Anlass für die Kartierung. Wir arbeiten aus dem Code und den verfügbaren Quellen heraus.
Dieser Beitrag ist ein informativer Überblick und keine Rechtsberatung.