Hochverfügbarkeit und Disaster Recovery gehören seit Jahrzehnten zu den Kerndisziplinen professioneller IT. Doch ein erfolgreich gestartetes System bedeutet noch lange nicht, dass auch der dahinterliegende Geschäftsprozess wieder funktioniert. Gerade bei über Jahrzehnte gewachsenen Legacy-Anwendungen stellt sich deshalb eine weitergehende Frage: Können Unternehmen nicht nur ihre Systeme und Daten wiederherstellen, sondern auch das Wissen, das in ihnen steckt?

Mainframe-Umgebungen haben einen Ruf zu verlieren. Sie gelten als besonders zuverlässig, hochverfügbar und robust. Dieser Ruf kommt nicht von ungefähr. Über Jahrzehnte wurden Architekturen und Verfahren entwickelt, mit denen sich Hardwareausfälle, Störungen einzelner Komponenten oder sogar der Verlust ganzer Standorte beherrschen lassen.

Bei Diskussionen über Resilienz standen deshalb lange vor allem technische Fragen im Mittelpunkt. Wie schnell kann ein System wieder gestartet werden? Wie lässt sich auf einen anderen Standort umschalten? Wie aktuell ist die verfügbare Datenkopie? Und wie viel Ausfallzeit kann ein Unternehmen überhaupt verkraften?

Rebecca Levesque stellt in ihrem IBM-Community-Beitrag „Always Available Does Not Mean Always Recoverable“ eine einfache, aber ausgesprochen wichtige Frage: Reicht das wirklich?

Ihre Kernaussage ist, dass Verfügbarkeit und Wiederherstellbarkeit zwei unterschiedliche Dinge sind. Ein System kann technisch verfügbar sein und trotzdem Daten enthalten, die unvollständig, inkonsistent oder nicht mehr vertrauenswürdig sind. Ebenso kann die Infrastruktur längst wieder funktionieren, während der eigentliche Geschäftsprozess weiterhin stillsteht.

Vielen Dank an Rebecca Levesque für den Anstoß zu diesen Überlegungen.

Ein grüner Systemstatus beantwortet nur einen Teil der Frage

Das Problem beginnt schon bei der Frage, was eigentlich wiederhergestellt werden soll.

Aus technischer Sicht kann die Lage eindeutig aussehen. Das Betriebssystem läuft, die Datenbank ist verfügbar, das Transaktionssystem wurde gestartet und die Batchverarbeitung wartet auf Arbeit. Die Überwachung zeigt grüne Zustände und aus Sicht des Betriebs scheint die Welt wieder in Ordnung zu sein.

Für das Unternehmen kann die Situation trotzdem vollkommen anders aussehen.

Ein Geschäftsprozess besteht schließlich nicht aus einem Betriebssystem, einer Datenbank oder einem einzelnen Programm. Er entsteht durch das Zusammenspiel von Anwendungen, Daten, Schnittstellen, Batchabläufen, Geschäftsregeln und organisatorischen Zuständigkeiten. Häufig gehören auch manuelle Tätigkeiten dazu, die irgendwann einmal Teil eines technischen oder fachlichen Ablaufes geworden sind.

Deshalb ist die entscheidende Frage nicht, ob ein Server erreichbar ist oder ein Subsystem wieder gestartet wurde.

Sie lautet vielmehr: Kann das Unternehmen seinen kritischen Geschäftsprozess wieder zuverlässig ausführen?

Und genau hier wird aus einem technischen Recovery-Thema sehr schnell eine Frage des fachlichen Verständnisses.

Replikation kann auch den Fehler perfekt replizieren

Besonders deutlich wird der Unterschied bei logischen Fehlern.

Ein technischer Ausfall ist vergleichsweise leicht zu erkennen. Eine Komponente funktioniert nicht mehr, fällt aus oder wird durch eine andere übernommen. Schwieriger wird es, wenn technisch zunächst alles funktioniert, die Ergebnisse aber fachlich falsch sind.

Ein fehlerhaftes Programm kann falsche Daten erzeugen. Ein Bedienfehler kann Datensätze verändern oder löschen. Eine neue Programmversion kann über Stunden Transaktionen verarbeiten, die technisch korrekt aussehen, fachlich aber nicht stimmen. Auch ein Angriff muss nicht zwangsläufig dazu führen, dass ein System sofort ausfällt. Daten können manipuliert werden, während die Infrastruktur weiterhin vollkommen unauffällig arbeitet.

Hochverfügbarkeit verhindert solche Fehler nicht automatisch.

Im Gegenteil: Gute Replikation ist ausgesprochen effizient darin, Veränderungen weiterzugeben. Leider unterscheidet sie dabei nicht unbedingt zwischen einer gewünschten Änderung und einem Fehler. Im ungünstigsten Fall besitzt ein Unternehmen deshalb nicht mehrere sichere Kopien seiner Daten, sondern mehrere sehr aktuelle Kopien desselben Problems.

Damit entsteht eine wesentlich schwierigere Frage:

Welcher Zustand war der letzte fachlich korrekte Zustand?

Um diese Frage beantworten zu können, reicht technisches Wissen allein nicht aus. Man muss verstehen, was das System eigentlich tut.

Was muss gemeinsam wiederhergestellt werden?

Gerade bei lange gewachsenen Unternehmensanwendungen ist ein Geschäftsprozess selten auf ein einzelnes Programm oder eine einzelne Datenbank begrenzt.

Ein Vorgang kann in einer Online-Anwendung beginnen, anschließend mehrere Datenbestände verändern und eine Nachricht an ein anderes System erzeugen. Stunden später greift ein Batchlauf diese Informationen auf, verarbeitet sie weiter und übergibt das Ergebnis an ein Reporting-System, eine Schnittstelle oder ein anderes Fachverfahren.

Jede einzelne technische Komponente kann für sich betrachtet vollkommen gesund sein. Trotzdem kann der gesamte Ablauf fachlich beschädigt sein.

Dieses Problem ist nicht auf eine bestimmte Plattform beschränkt. Es betrifft z/OS ebenso wie VSEn und selbstverständlich auch verteilte Systeme oder moderne Cloud-Architekturen.

Bei Legacy-Systemen kommt allerdings eine Besonderheit hinzu. Viele dieser Anwendungen sind über Jahrzehnte gewachsen. Sie wurden erweitert, angepasst, mit neuen Funktionen versehen und immer wieder an neue fachliche Anforderungen angepasst. Manche Komponenten wurden ersetzt, andere blieben bestehen. Neue Schnittstellen kamen hinzu, alte Abläufe wurden nie vollständig entfernt.

Das Ergebnis ist häufig weit mehr als eine technische Anwendung.

Es ist ein Stück Unternehmensgeschichte, das ausführbar geworden ist.

Legacy-Code enthält mehr als Programmcode

Wenn über Wissensverlust in der Legacy-IT gesprochen wird, fällt sehr schnell das Stichwort COBOL. Das ist nachvollziehbar, greift aber zu kurz.

Dasselbe Problem betrifft PL/I, Assembler, RPG, Natural, Fortran und viele weitere Sprachen und Technologien, die seit Jahrzehnten produktive Geschäftsprozesse tragen. Dazu kommen Jobsteuerung, Skriptsprachen, proprietäre 4GL-Umgebungen, Datenbankprozeduren und zahllose technische Konstrukte, die irgendwann einmal aus einem konkreten fachlichen Bedarf entstanden sind.

Die eigentliche Herausforderung besteht dabei nicht darin, dass irgendwann niemand mehr eine bestimmte Syntax kennt.

COBOL kann man lernen. PL/I kann man lernen. Auch Assembler lässt sich lernen, ebenso RPG oder eine andere Sprache, die heute vielleicht nicht mehr an jeder Hochschule unterrichtet wird.

Deutlich schwieriger ist die Frage, warum ein Programm genau das tut, was es tut.

Warum wird bei einer bestimmten Kundengruppe anders gerechnet? Warum existiert vor einem Monatsabschluss noch ein zusätzlicher Verarbeitungsschritt? Warum darf ein Datenfeld in einem bestimmten Fall nicht geändert werden? Warum ruft ein Programm eine scheinbar überflüssige Routine auf? Warum wird eine Datei nachts noch einmal sortiert, obwohl die Daten bereits korrekt erscheinen?

Die Antworten darauf stehen nicht zwangsläufig in der Programmiersprache.

Sie können sich in einem COBOL-Programm verstecken, in einer PL/I-Routine, in einigen Zeilen Assembler, in einem RPG-Programm oder in einem Job, der seit zwanzig Jahren jeden Abend um 23:15 Uhr ausgeführt wird. Vielleicht liegt ein Teil der Logik in einer Tabelle, ein anderer in einem Copybook und der Rest in einer Betriebsanweisung, die irgendwann einmal aus einer regulatorischen Änderung hervorgegangen ist.

Genau deshalb ist es gefährlich, Legacy-Systeme auf ihre Sprache zu reduzieren.

Das eigentliche Legacy ist nicht COBOL, PL/I, Assembler oder RPG. Das eigentliche Legacy ist häufig das darin gespeicherte und nur noch teilweise dokumentierte Geschäftswissen.

Einige Regeln sind hervorragend dokumentiert. Andere lassen sich nur noch aus dem Code rekonstruieren. Und manches Wissen befindet sich überhaupt nicht in einem technischen Artefakt, sondern im Kopf eines Menschen, der seit dreißig Jahren weiß, warum ein bestimmter Ablauf niemals verändert werden durfte.

Solche Gespräche beginnen dann manchmal mit dem Satz:

„Das muss unbedingt vor diesem Job laufen.“

Auf die Frage nach dem Grund folgt gelegentlich ein Schulterzucken.

„Das war schon immer so.“

Das klingt zunächst harmlos. In Wirklichkeit beschreibt dieser Satz ein erhebliches Risiko.

Geschäftswissen wird selbst zum Recovery-Asset

Wenn für die Wiederherstellung eines Geschäftsprozesses Kenntnisse über Anwendungen, Daten und Abhängigkeiten notwendig sind, dann gehört dieses Wissen faktisch zur Recovery-Fähigkeit eines Unternehmens.

In der Praxis werden technische Recovery-Pläne und Anwendungswissen trotzdem häufig getrennt betrachtet.

Auf der einen Seite existieren Betriebshandbücher, Sicherungskonzepte und Wiederanlaufverfahren. Auf der anderen Seite gibt es Architekturdiagramme, Dokumentationen, Tickets, Wiki-Seiten, alte Projektunterlagen und das Erfahrungswissen einzelner Mitarbeiter.

Im Ernstfall müssen diese Welten plötzlich zusammenpassen.

Ein Recovery-Konzept, das genau beschreibt, welches Dataset wiederhergestellt werden muss, aber nicht erklären kann, welcher Geschäftsprozess anschließend davon abhängt, besitzt nur einen Teil der notwendigen Information.

Das gilt auch umgekehrt. Eine hervorragend dokumentierte Fachlogik hilft wenig, wenn niemand mehr weiß, welche technische Komponente diese Logik tatsächlich umsetzt.

Die entscheidende Verbindung lautet deshalb:

Geschäftsprozess – Geschäftsregel – Anwendung – Programm – Daten – Verarbeitung – Schnittstelle.

Je besser diese Kette nachvollziehbar ist, desto belastbarer wird nicht nur das Recovery. Auch Wartung, Fehleranalyse und Modernisierung werden einfacher.

Der Generationenwechsel verschärft das Problem

Diese Fragestellung wird zusätzlich dadurch relevant, dass viele Unternehmen derzeit einen Generationenwechsel erleben.

Erfahrene Entwickler, Systemprogrammierer und Anwendungsspezialisten gehen nach Jahrzehnten in den Ruhestand. Neue Kolleginnen und Kollegen übernehmen Systeme, die oftmals älter sind als sie selbst.

Das ist zunächst kein grundsätzliches Problem. Technologie wurde immer von einer Generation an die nächste weitergegeben.

Problematisch wird es dort, wo Wissen nie vollständig dokumentiert wurde.

Ein Entwickler, der zwanzig oder dreißig Jahre an einem System gearbeitet hat, kennt Zusammenhänge, die kein Architekturdiagramm vollständig erfassen kann. Er weiß vielleicht, welche Anwendung bei Monatsende besonders kritisch ist, welche Batchkette auf keinen Fall unterbrochen werden darf und warum ein scheinbar merkwürdiger Programmpfad keinesfalls entfernt werden sollte.

Wenn dieser Mensch das Unternehmen verlässt, läuft die Anwendung zunächst weiter.

Und genau darin liegt das Risiko.

Technische Schulden melden sich irgendwann durch hohe Wartungskosten oder zunehmende Probleme.

Wissensschulden können sehr lange unsichtbar bleiben.

Sie werden häufig erst dann sichtbar, wenn etwas Ungewöhnliches passiert.

Eine große Änderung steht an. Ein Fehler lässt sich nicht erklären. Eine Migration beginnt. Oder nach einem Zwischenfall muss plötzlich entschieden werden, welche Komponenten gemeinsam auf welchen Stand zurückgesetzt werden müssen.

Dann wird Wissen vom angenehmen Zusatz zur betrieblichen Voraussetzung.

KI kann helfen, aber sie kennt die fachliche Wahrheit nicht

An dieser Stelle wird künstliche Intelligenz interessant.

Dabei liegt der möglicherweise wichtigste Nutzen von KI in der Legacy-IT nicht einmal in der automatischen Übersetzung einer alten Programmiersprache in eine neue.

Die spannendere Aufgabe könnte zunächst darin bestehen, bestehende Systeme wieder verständlich zu machen.

KI kann Quellcode analysieren, Aufrufhierarchien untersuchen, Datenstrukturen miteinander in Beziehung setzen und wiederkehrende fachliche Muster erkennen. Sie kann Jobketten analysieren, Schnittstellenbeziehungen sichtbar machen und Dokumentation mit tatsächlichem Programmverhalten vergleichen.

Das kann bei COBOL ebenso funktionieren wie bei PL/I, Assembler, RPG und anderen Legacy-Technologien.

Gerade dort, wo Informationen über viele technische Artefakte verteilt sind, entsteht ein interessanter Ansatz. Statt jedes Programm isoliert zu betrachten, kann versucht werden, Zusammenhänge über Sprach- und Systemgrenzen hinweg zu rekonstruieren.

Aus vielen einzelnen technischen Informationen entsteht dann nach und nach wieder ein Bild:

Welcher Geschäftsprozess verwendet welche Daten? Welche Programme setzen welche Regeln um? Welche Jobs verarbeiten diese Informationen weiter? Welche Schnittstellen hängen davon ab?

Das ist für Modernisierung interessant, aber ebenso für Recoverability.

Allerdings besitzt KI eine entscheidende Grenze.

Eine KI kann möglicherweise erkennen, dass eine bestimmte Regel seit zwanzig Jahren im Programm steht.

Sie weiß deshalb noch lange nicht, ob diese Regel heute noch fachlich richtig ist.

Sie kann Zusammenhänge finden, Hinweise liefern und Hypothesen erzeugen. Fachliche Wahrheit entsteht daraus noch nicht automatisch.

Deshalb bleibt die Validierung durch Menschen unverzichtbar. Im besten Fall hilft KI dabei, die richtigen Fragen schneller zu stellen und längst vergessene Zusammenhänge wieder sichtbar zu machen.

Recoverability und Modernisierung liegen näher beieinander, als man zunächst denkt

Damit führt die Diskussion über Recoverability fast zwangsläufig zur Modernisierung.

Ein Unternehmen, das seine eigenen Anwendungen nicht ausreichend versteht, besitzt nicht nur ein Recovery-Problem. Es besitzt auch ein Modernisierungsproblem.

Denn vor jeder Migration, Transformation oder Neuimplementierung steht dieselbe Frage:

Was muss eigentlich erhalten bleiben?

Wer darauf nur mit einer Liste von Programmen, Tabellen, Jobs und Schnittstellen antworten kann, beschreibt vor allem die technische Oberfläche eines Systems.

Modernisierung benötigt jedoch das fachliche Verhalten.

Sie muss Geschäftsregeln, Abhängigkeiten, Sonderfälle und häufig auch jene Merkwürdigkeiten berücksichtigen, die aus Sicht eines neuen Entwicklungsteams zunächst wie überflüssiger Legacy-Code aussehen.

Manche davon sind tatsächlich historischer Ballast.

Andere existieren aus ausgesprochen guten Gründen.

Das Problem besteht darin, beide voneinander zu unterscheiden.

Eine automatische Transformation kann technisch perfekt funktionieren und trotzdem fachlich das falsche Ergebnis liefern.

Deshalb gilt auch für Modernisierung:

Man kann das Falsche sehr effizient modernisieren.

Recovery als Architekturtest

Vielleicht bietet die Frage der Wiederherstellbarkeit deshalb einen erstaunlich guten Test für die eigene Systemdokumentation.

Statt zu fragen:

„Welche Komponenten benötigen wir, damit das System wieder startet?“

könnte man eine andere Frage stellen:

„Welche Informationen benötigen wir, um nach einem unbekannten Datenfehler wieder einen fachlich vertrauenswürdigen Zustand herzustellen?“

Die Antwort darauf sagt viel über den tatsächlichen Zustand einer Systemlandschaft aus.

Wenn dafür mehrere ehemalige Entwickler angerufen, alte Excel-Dateien gesucht, historische Tickets ausgewertet und zehn unterschiedliche Dokumentationen miteinander verglichen werden müssen, dann existiert ein Risiko. Und zwar unabhängig davon, wie zuverlässig die technische Infrastruktur funktioniert.

Eine belastbare Antwort müsste wesentlich weiter reichen.

Sie müsste zeigen, welche Geschäftsprozesse betroffen sind, welche Anwendungen daran beteiligt sind, welche Daten gemeinsam betrachtet werden müssen und welche zeitlichen Abhängigkeiten bestehen. Ebenso wichtig ist die Frage, wie anschließend geprüft werden kann, ob das Ergebnis nicht nur technisch konsistent, sondern auch fachlich korrekt ist.

Denn ein Administrator kann feststellen, dass eine Datei erfolgreich wiederhergestellt wurde.

Ob darin anschließend wieder der richtige Vertrag, der korrekte Kontostand oder der vollständige Verwaltungsfall abgebildet ist, ist eine andere Frage.

Recover the Business

Die Ausgangsthese von Rebecca Levesque lässt sich deshalb noch etwas weiterführen:

Always available does not mean always recoverable.

Aber auch „recoverable“ sollten wir vielleicht nicht ausschließlich technisch verstehen.

Ein resilientes Unternehmen muss nicht nur Infrastruktur, Anwendungen und Daten wiederherstellen können. Es muss auch verstehen, wie diese Komponenten gemeinsam das Geschäft abbilden.

Gerade bei lange gewachsenen z/OS- und VSEn-Anwendungen ist dieses Wissen häufig über viele technische Schichten, Programmiersprachen und Generationen von Entwicklern verteilt.

COBOL ist dabei nur ein Teil der Geschichte. Dasselbe gilt für PL/I, Assembler, RPG und zahlreiche andere Technologien, die oft seit Jahrzehnten zuverlässig ihren Dienst tun und dabei Geschäftslogik transportieren, die nirgendwo sonst vollständig beschrieben ist.

KI kann helfen, diese Zusammenhänge wieder sichtbar zu machen. Sie kann Quellcode analysieren, Beziehungen entdecken und Dokumentationslücken verkleinern.

Die entscheidende Aufgabe bleibt jedoch menschlich: Aus technischen Zusammenhängen wieder ein belastbares Verständnis des Geschäfts zu machen.

Vielleicht wird deshalb neben RTO, RPO und Verfügbarkeit künftig noch eine andere Frage wichtiger:

Können wir nicht nur unsere Systeme wiederherstellen, sondern auch das Wissen, das wir benötigen, um ihnen anschließend wieder zu vertrauen?

Denn ein grüner Systemstatus ist zweifellos beruhigend.

Am Ende zählt für ein Unternehmen aber etwas anderes:

Das Geschäft muss wieder funktionieren.

Über den Autor: Uwe Graf ist Head of Consulting bei der EasiRun Europa GmbH und gilt auf LinkedIn als eine der profiliertesten Stimmen in Sachen Mainframe-Modernisierung. Seine Beiträge sind fachlich präzise, pointiert – und unverkennbar durch den kleinen Dino, der als Symbol für den Brückenschlag zwischen Tradition und Innovation steht. Für sein Engagement in der Mainframe-Community wurde er 2025 sowohl als IBM Champion als auch als „Influential Mainframer“ von planetmainframe.com ausgezeichnet