Es gibt eine erstaunlich hartnäckige Erzählung in der IT-Welt: Der Mainframe gilt als Relikt, DevOps als Rettung und die Cloud als Zielzustand. Diese Geschichte ist eingängig, einfach zu kommunizieren – und in der Praxis oft grundlegend falsch.

Denn wer heute einen realistischen Blick in große Organisationen wirft, erkennt schnell: Der Mainframe ist weder verschwunden noch auf dem Rückzug. Im Gegenteil. Er ist nach wie vor das stabile Rückgrat geschäftskritischer Prozesse. Gleichzeitig befindet sich genau dieses Rückgrat mitten in einem Umfeld, das sich in den letzten Jahren radikal verändert hat. Cloud-native Architekturen, API-getriebene Integration, eventbasierte Systeme und kontinuierliche Softwarebereitstellung sind längst Standard geworden. Nur eines hat sich vielerorts nicht im gleichen Maß weiterentwickelt: die Art und Weise, wie wir den Mainframe in dieses Gesamtbild einordnen.

Genau hier beginnt das eigentliche Missverständnis. In vielen Unternehmen wird DevOps auf dem Mainframe als eine Art Modernisierungs-Upgrade verstanden, das sich primär über neue Werkzeuge definiert. Git wird eingeführt, CI/CD-Pipelines werden aufgebaut, moderne Entwicklungsumgebungen ersetzen klassische Interfaces. All das sind sinnvolle und notwendige Schritte. Und dennoch bleibt oft das Gefühl zurück, dass sich der erwartete Effekt nicht wirklich einstellt. Prozesse werden schneller, aber nicht unbedingt besser. Die Zusammenarbeit verändert sich kaum. Die Organisation wirkt weiterhin fragmentiert.

Der Grund dafür ist so simpel wie unbequem: DevOps ist kein Tooling-Thema. Es ist ein Betriebsmodell. Es beschreibt nicht, welche Werkzeuge eingesetzt werden, sondern wie Menschen, Prozesse und Technologie zusammenspielen. Und genau dieses Zusammenspiel ist auf dem Mainframe besonders anspruchsvoll, weil hier über Jahrzehnte gewachsene Strukturen auf moderne Anforderungen treffen.

Mainframe ist kein isoliertes System

Die vielleicht wichtigste Veränderung, die in vielen Diskussionen noch unterschätzt wird, ist die Tatsache, dass der Mainframe heute kein isoliertes System mehr ist. Früher konnte man ihn relativ klar als abgeschlossene Welt betrachten. Heute ist er integraler Bestandteil komplexer, verteilter Architekturen. APIs verbinden ihn mit Frontend-Systemen, Events transportieren Daten in Echtzeit in andere Plattformen, Cloud-Anwendungen greifen direkt auf Transaktionen zu. Das bedeutet, dass jede Veränderung auf dem Mainframe potenziell Auswirkungen auf eine Vielzahl anderer Systeme hat. DevOps auf dem Mainframe ist damit nicht mehr nur eine Frage von Build, Test und Deployment innerhalb einer Plattform, sondern eine Frage von durchgängiger Verantwortung über Systemgrenzen hinweg.

Im z/OS-Umfeld zeigt sich dieser Wandel besonders deutlich. Hier trifft eine Kultur, die über Jahrzehnte auf maximale Stabilität, Kontrolle und Risikominimierung ausgelegt war, auf eine Welt, die Geschwindigkeit, Flexibilität und kontinuierliche Veränderung verlangt. Diese beiden Logiken stehen nicht im Widerspruch, aber sie lassen sich auch nicht trivial miteinander vereinen. Viele Organisationen befinden sich deshalb in einem Zwischenzustand. Sie haben moderne Werkzeuge eingeführt, arbeiten aber weiterhin nach alten Mustern. Releases sind zwar technisch automatisiert, organisatorisch aber weiterhin selten und hochsensibel. Verantwortung wird formal erweitert, praktisch aber weiterhin entlang klassischer Grenzen verteilt. DevOps wird eingeführt, ohne dass sich die zugrunde liegende Denkweise wirklich verändert.

Noch deutlicher wird diese Komplexität im VSEn-Umfeld. Hier ist die Situation oft weniger homogen als bei z/OS. Statt einer klar definierten Entwicklungs- und Betriebswelt existieren mehrere Realitäten parallel. Auf der einen Seite steht die Entwicklung über z/VM, die sich vergleichsweise gut in moderne, teilweise cloud-nahe Workflows integrieren lässt. Auf der anderen Seite existieren ICCF-basierte Ansätze, die tief in den operativen Prozessen verankert sind und deren Stabilität über Jahre hinweg erprobt wurde. Diese Koexistenz ist kein temporärer Zustand, sondern gelebte Realität in vielen Organisationen. Und genau deshalb greifen klassische Modernisierungsstrategien hier häufig zu kurz.

Denn es geht nicht darum, eine dieser Welten durch die andere zu ersetzen. Es geht darum, sie miteinander zu verbinden. Das ist kein rein technisches Problem, sondern ein strukturelles. Unterschiedliche Entwicklungsmodelle, unterschiedliche Geschwindigkeiten, unterschiedliche Erwartungen müssen in Einklang gebracht werden. Gleichzeitig müssen diese Systeme in eine Gesamtarchitektur eingebettet werden, die zunehmend durch Cloud-Komponenten geprägt ist.

Cloud ist kein Zielzustand

An dieser Stelle kommt ein weiterer Denkfehler ins Spiel: die Vorstellung, die Cloud sei ein Zielzustand. In Wirklichkeit ist sie längst der Kontext, in dem moderne IT stattfindet. Systeme existieren nicht mehr isoliert, sondern sind Teil eines Netzwerks aus Plattformen, Services und Datenflüssen. Der Mainframe liefert Daten für Cloud-Anwendungen, Cloud-Services greifen auf Mainframe-Funktionalität zu, Geschäftsprozesse verlaufen über mehrere Systeme hinweg. DevOps muss genau dieses Zusammenspiel unterstützen. Wer den Mainframe ohne Cloud-Kontext betrachtet, verpasst einen wesentlichen Teil der Realität.

Viele DevOps-Initiativen auf dem Mainframe scheitern oder stagnieren genau aus diesem Grund. Sie konzentrieren sich auf einzelne Aspekte, ohne das Gesamtsystem zu berücksichtigen. Werkzeuge werden eingeführt, ohne Prozesse zu hinterfragen. Automatisierung wird aufgebaut, ohne die zugrunde liegende Logik vollständig zu verstehen. Teams arbeiten weiterhin in getrennten Strukturen, während die Systeme längst miteinander verflochten sind. Das Ergebnis ist eine Modernisierung auf der Oberfläche, die jedoch nicht zu einer echten Transformation führt.

Erfolgreiche Ansätze gehen einen anderen Weg. Sie beginnen nicht mit Technologie, sondern mit einem ehrlichen Blick auf die bestehenden Abläufe. Sie fragen nicht zuerst, welche Tools eingesetzt werden sollen, sondern wie Arbeit tatsächlich organisiert ist, wo Brüche entstehen und welche Abhängigkeiten bestehen. Sie akzeptieren, dass nicht alles gleichzeitig modernisiert werden kann, aber dass alles verstanden werden muss. Gerade im VSEn-Umfeld zeigt sich, dass Evolution oft der einzige realistische Weg ist. Schrittweise Integration, gezielte Automatisierung und bewusste Gestaltung von Schnittstellen führen hier weiter als radikale Umbrüche.

Legacy und Innovation müssen verbunden werden

Am Ende läuft alles auf einen zentralen Punkt hinaus: DevOps auf dem Mainframe ist ein Balanceakt. Es geht nicht darum, Stabilität gegen Geschwindigkeit auszutauschen oder Legacy durch Innovation zu ersetzen. Es geht darum, beides miteinander zu verbinden. Es geht darum, bestehende Stärken zu erhalten und gleichzeitig neue Anforderungen zu integrieren. Es geht darum, den Mainframe nicht als Sonderfall zu behandeln, sondern als gleichberechtigten Teil einer modernen IT-Landschaft.

Vielleicht ist es an der Zeit, die Diskussion etwas ehrlicher zu führen. Das Problem ist nicht COBOL, nicht z/OS und auch nicht VSEn. Das Problem ist die Perspektive, aus der wir auf diese Systeme schauen. Solange DevOps als reines Tool-Projekt verstanden wird, solange die Cloud als Ziel statt als Kontext gesehen wird und solange der Mainframe isoliert betrachtet wird, werden wir weiterhin optimieren, ohne wirklich zu transformieren.

Der Mainframe ist kein Auslaufmodell. Er ist Teil der Gegenwart und wird es auf absehbare Zeit bleiben. Die entscheidende Frage ist daher nicht, ob wir ihn modernisieren, sondern wie wir ihn sinnvoll in das Gesamtbild integrieren. DevOps kann dabei eine zentrale Rolle spielen – aber nur dann, wenn wir es als das begreifen, was es wirklich ist: ein organisatorischer Wandel mit technischen Konsequenzen, in einer Welt, in der Mainframe und Cloud längst zusammengehören.

Ü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