Wenn über den Mainframe-Skills-Gap gesprochen wird, ist die Geschichte meistens schnell erzählt. Erfahrene Spezialisten gehen in den Ruhestand, Nachwuchs fehlt, und mit jedem ausscheidenden Kollegen droht Wissen über COBOL, CICS, Db2, RACF, JCL oder z/OS verloren zu gehen. Das Problem ist real, und es wäre falsch, es kleinzureden. Trotzdem habe ich zunehmend den Eindruck, dass diese Beschreibung nur noch einen Teil der tatsächlichen Herausforderung erfasst.
Denn während wir darüber diskutieren, wie viele Mainframe-Spezialisten in den kommenden Jahren fehlen könnten, hat sich deren Arbeitsumgebung längst grundlegend verändert. Eine geschäftskritische Anwendung besteht heute nur noch selten aus einem klar abgegrenzten z/OS-System. Eine einzelne Transaktion kann über ein Web-Frontend und eine API beginnen, anschließend einen verteilten Java-Service durchlaufen, über MQ auf den Mainframe gelangen, in CICS verarbeitet werden, Daten aus Db2 holen und danach noch einen Cloud-Service oder einen externen Dienst aufrufen.
Solange alles funktioniert, nennen wir das eine moderne hybride Architektur. Wenn etwas nicht funktioniert, wird dieselbe Architektur sehr schnell zu einem Diagnoseproblem.
Genau deshalb lohnt sich eine etwas andere Betrachtung des Mainframe-Skills-Gaps. Möglicherweise besteht der Engpass der nächsten Jahre nicht nur darin, dass uns Menschen fehlen, die einzelne Mainframe-Technologien beherrschen. Mindestens ebenso problematisch könnte werden, dass immer weniger Menschen den gesamten Weg einer geschäftlichen Transaktion über mehrere technische Welten hinweg nachvollziehen können.
Eine aktuelle Analyse von Tim Willging, CTO Mainframe bei Rocket Software, greift genau diese These auf. Der Beitrag auf Planet Mainframe ist von Rocket Software gesponsert und sollte deshalb auch als Herstellerperspektive gelesen werden. Die zugrunde liegenden Zahlen stammen allerdings aus einer im Juni 2026 von Hanover Research durchgeführten Befragung von 250 IT-Verantwortlichen aus Banken und Finanzdienstleistern in den USA, Großbritannien, Frankreich, Deutschland und den Niederlanden.
Der klassische Skills Gap verschwindet nicht, aber er bekommt Gesellschaft
Die Zahlen der Hanover-Untersuchung zeigen zunächst, dass der klassische Fachkräftemangel keineswegs erledigt ist. 81 Prozent der befragten Führungskräfte aus dem Banken- und Finanzdienstleistungssektor bezeichneten ihre Mainframe-Kompetenzlücke als sehr oder extrem bedeutend. Gleichzeitig berichteten 51 Prozent von Schwierigkeiten bei der Verbindung von Cloud- und On-Premises-Umgebungen. Die entsprechende Veröffentlichung von Rocket Software findet sich hier.
Diese Kombination ist bemerkenswert. Auf der einen Seite fehlt tiefes Plattformwissen, auf der anderen Seite wird genau diese Plattform immer stärker mit anderen Systemwelten verbunden. Damit steigt nicht nur die Zahl der Technologien, die ein Unternehmen betreiben muss, sondern vor allem die Zahl der Beziehungen zwischen diesen Technologien.
Ein erfahrener CICS-Spezialist kann sehr genau analysieren, warum eine bestimmte Transaktion innerhalb von CICS ungewöhnlich lange läuft. Ein Db2-Spezialist kennt die Accounting-Daten und kann beurteilen, ob sich Zugriffszeiten oder Locking-Verhalten verändert haben. Das API-Team wiederum sieht seine Response Times und Fehlercodes, während das Cloud-Team die Telemetrie seiner Services kennt.
Das Problem beginnt dort, wo jede dieser Einzelbeobachtungen für sich genommen plausibel aussieht und trotzdem der gesamte Geschäftsprozess zu langsam ist.
Dann reicht es eben nicht mehr, ein Werkzeug besonders gut bedienen zu können. Jemand muss erkennen, dass die fünf Millisekunden zusätzliche Zeit im API Gateway vielleicht überhaupt keine Rolle spielen, während ein veränderter Datenbankzugriff auf Db2 dazu führt, dass eine CICS-Transaktion deutlich länger Ressourcen hält und dadurch an einer ganz anderen Stelle Wartesituationen entstehen.
Diese Art von Wissen ist schwerer zu vermitteln als die Bedienung eines Werkzeugs, weil sie nicht nur technisches Wissen voraussetzt, sondern Erfahrung mit Zusammenhängen.
Hybrid ist längst kein Übergangszustand mehr
Dass diese Situation keine Ausnahme mehr ist, zeigt auch der Arcati Mainframe Navigator 2026. Dort berichten 30 Prozent der Teilnehmer von einer stark integrierten hybriden Mainframe-Umgebung, weitere 39 Prozent von einer zumindest teilweise integrierten Umgebung. Als größte Herausforderung in hybriden Landschaften nennen 43 Prozent Observability und Performance Monitoring. Die entsprechenden Ergebnisse sind bei Planet Mainframe dokumentiert beziehungsweise ausführlicher beschrieben.
Das ist für mich ein wichtiger Punkt, weil hybride Architekturen häufig noch so diskutiert werden, als befänden sich Unternehmen auf dem Weg von einer alten zu einer neuen Welt. In vielen Rechenzentren ist Hybrid inzwischen aber schlicht der Normalzustand. Der Mainframe bleibt System of Record für bestimmte Prozesse, während APIs, Cloud-Services, SaaS-Anwendungen und verteilte Plattformen darum herum zusätzliche Funktionen übernehmen.
Damit entsteht eine Architektur, die fachlich durchaus sinnvoll sein kann, betrieblich aber eine neue Art von Komplexität erzeugt.
Ein Fehler kennt schließlich keine organisatorischen Teamgrenzen. Eine Kundenüberweisung interessiert sich nicht dafür, ob ihr erster Teil auf Kubernetes, ihr zweiter über MQ und ihr dritter in CICS läuft. Für den Kunden gibt es nur eine Transaktion, die funktioniert oder eben nicht funktioniert.
Unsere Monitoring- und Supportstrukturen sehen diese Welt häufig sehr viel fragmentierter.
Aus einem Performanceproblem wird schnell ein Detektivfall
Nehmen wir eine Bankanwendung als Beispiel. Ein Kunde bestätigt in einer mobilen Anwendung eine Zahlung. Die Anfrage läuft über einen API-Gateway, wird von einem verteilten Service geprüft, erreicht anschließend über MQ eine CICS-Anwendung und schreibt Daten nach Db2. Parallel wird möglicherweise ein externer Fraud-Detection-Service aufgerufen.
Am Morgen funktioniert dieser Ablauf in 300 Millisekunden. Zwei Stunden später sind es plötzlich zwei Sekunden.
Für die Organisation beginnt jetzt eine Suche, bei der jede beteiligte Gruppe zunächst auf die eigene Sicht schaut. Das Mobile-Team sieht keine Auffälligkeiten, der API-Gateway meldet normale Auslastung, MQ zeigt keine außergewöhnlichen Queue Depths und CICS läuft ebenfalls nicht an seiner Kapazitätsgrenze. Trotzdem ist der Geschäftsprozess langsam.
Die eigentliche Kompetenz besteht in einer solchen Situation nicht darin, möglichst schnell noch mehr Dashboards zu öffnen. Sie besteht darin, Hypothesen zu bilden und herauszufinden, welche Daten überhaupt miteinander verglichen werden müssen.
Ein erfahrener Spezialist entwickelt dafür im Laufe der Jahre ein Gespür. Er weiß beispielsweise, dass eine veränderte Response Time allein wenig aussagt und untersucht deshalb, ob gleichzeitig Db2-Wartezeiten gestiegen sind, ob sich ein SQL-Zugriff geändert hat, ob eine Anwendung häufiger externe Services aufruft oder ob kurz zuvor ein Change produktiv gesetzt wurde.
Dieses Wissen ist kaum vollständig in einem Handbuch dokumentiert. Es entsteht durch viele reale Produktionsprobleme und durch die Erfahrung, welche Signale wichtig waren und welche nur zufällig gleichzeitig auftraten.
Genau an dieser Stelle wird operative Komplexität zu einem Skills-Thema.
Monitoring und Observability sind nicht dasselbe
Die Mainframe-Welt hat bei der Diagnose einen großen Vorteil: Sie produziert seit Jahrzehnten ausgesprochen detaillierte Betriebsdaten. SMF, CICS-Monitoring, Db2 Accounting, RMF, MQ-Statistiken und spezialisierte Monitoring-Produkte liefern eine Tiefe, um die andere Plattformen den Mainframe teilweise beneiden könnten.
Das Problem besteht also nicht unbedingt darin, dass Daten fehlen.
Häufig fehlt die Verbindung zwischen ihnen.
Genau dort liegt der Unterschied zwischen klassischem Monitoring und dem, was heute unter Observability verstanden wird. Monitoring beantwortet sehr gut Fragen über einen bekannten Systembereich. Observability versucht zusätzlich zu zeigen, wie sich ein konkreter Vorgang über verschiedene Komponenten und Plattformen hinweg verhält.
Der OpenTelemetry-Ansatz ist dafür besonders interessant. OpenTelemetry beschreibt einen Trace als den Weg einer einzelnen Anfrage durch verschiedene Services. Über sogenannte Spans werden einzelne Verarbeitungsschritte erfasst, während ein gemeinsamer Trace Context dafür sorgt, dass diese Schritte trotz Prozess- und Netzwerkgrenzen wieder derselben Transaktion zugeordnet werden können. Die Grundlagen dazu beschreibt das OpenTelemetry-Projekt unter Context Propagation und im Observability Primer.
Das klingt zunächst sehr technisch, verändert aber die Fehlersuche erheblich. Wenn dieselbe Trace-ID von der Webanwendung über den API-Layer bis in die Mainframe-Verarbeitung weitergegeben werden kann, muss ein Spezialist nicht mehr ausschließlich anhand von Uhrzeiten, Transaktionsnamen und Erfahrungswerten rekonstruieren, welche Ereignisse wahrscheinlich zusammengehören.
Der technische Zusammenhang wird sichtbar.
OpenTelemetry ersetzt SMF nicht – und genau das ist wichtig
Gerade im Mainframe-Umfeld begegnet mir gelegentlich die Befürchtung, moderne Observability-Technologien sollten die etablierten Mainframe-Werkzeuge ersetzen. Das wäre aus meiner Sicht weder sinnvoll noch notwendig.
OpenTelemetry beantwortet eine andere Frage.
Ein Trace kann zeigen, dass eine Geschäftstransaktion 70 Prozent ihrer Zeit im Mainframe-Teil verbringt und dass davon wiederum ein bestimmter Abschnitt in Db2 auffällig ist. Für die eigentliche Ursachenanalyse benötigt der Db2-Spezialist anschließend aber weiterhin seine detaillierten Daten, genauso wie ein CICS-Spezialist die entsprechenden CICS-Informationen braucht.
OpenTelemetry zeigt also eher, wo man tiefer schauen sollte, während die etablierten Werkzeuge erklären, warum es dort ein Problem gibt.
IBM verfolgt genau diese Kombination. IBM Z Observability Connect soll Telemetriedaten von z/OS in unternehmensweite Observability-Plattformen einbinden und verwendet dafür OpenTelemetry. IBM beschreibt ausdrücklich das Ziel, hybride Geschäftstransaktionen von der Cloud bis zum Mainframe verfolgen und dadurch die Problemisolierung beschleunigen zu können.
Auch auf der Ebene einzelner Subsysteme wird diese Integration zunehmend konkreter. CICS TS 6.3 kann OpenTelemetry-Kontext empfangen, weiterreichen und eigene Span-Daten erzeugen. Die Konfiguration ist bei IBM beschrieben. IBM MQ für z/OS kann seine OpenTelemetry-Spans über SMF Type 1158 bereitstellen, wie IBM in seiner Dokumentation dokumentiert.
Das zeigt sehr schön, wie sich moderne Observability und klassische Mainframe-Telemetrie ergänzen können. Der Mainframe muss nicht aufhören, Mainframe zu sein, damit er innerhalb einer hybriden Anwendung besser sichtbar wird.
Db2 zeigt, wie beide Welten zusammenkommen können
Besonders anschaulich finde ich die Entwicklung bei Db2 for z/OS. Db2 13 unterstützt OpenTelemetry im Zusammenhang mit verteilten Traces, sodass eine Db2 Unit of Work Teil einer größeren Transaktionskette werden kann. Gleichzeitig bleibt die klassische SMF-basierte Sicht erhalten.
IBM hat dafür unter anderem IFCID 394 eingeführt, mit dem die OpenTelemetry-Aktivität innerhalb von Db2 selbst überwacht werden kann. Eine ausführliche Beschreibung findet sich in der IBM Community.
Das ist für mich ein sehr gutes Beispiel dafür, wie Mainframe-Modernisierung im Betrieb aussehen kann. Es entsteht nicht eine komplett neue Monitoring-Welt, die die alte ersetzt. Vielmehr wird eine zusätzliche Ebene geschaffen, die traditionelle Mainframe-Diagnose mit einem unternehmensweiten Transaktionskontext verbindet.
Gerade für den Skills-Gap ist das interessant, weil sich dadurch auch die Arbeitsteilung verändert. Ein zentraler Observability- oder SRE-Bereich kann möglicherweise erkennen, dass ein Problem tatsächlich im Db2-Teil einer Transaktion entsteht. Der Db2-Spezialist kann anschließend gezielter mit den Werkzeugen arbeiten, die für die detaillierte Analyse gedacht sind.
Dadurch wird sein Wissen nicht weniger wertvoll. Es wird im Gegenteil an der richtigen Stelle eingesetzt.
Der Fachkräftemangel ist real, aber mehr Personal allein löst das Problem nicht
An diesem Punkt sollte man die These von der operativen Komplexität nicht missverstehen. Natürlich brauchen Unternehmen weiterhin Mainframe-Spezialisten. Wer aus der wachsenden Komplexität ableiten würde, dass tiefes z/OS-Wissen weniger wichtig wird, käme zum genau falschen Ergebnis.
Interessant ist vielmehr, dass zusätzlich zum tiefen Spezialwissen eine zweite Kompetenzebene benötigt wird: die Fähigkeit, technische Signale in einen Gesamtzusammenhang einzuordnen.
Auch der Arcati Navigator zeigt diese Entwicklung. Rund 39 Prozent der Befragten berichten von Skills-Lücken unter anderem in Bereichen wie Security, Integration und Hybrid Environments. Gleichzeitig bleibt die Verantwortung für hochkritische Entscheidungen weiterhin bei erfahrenen Mitarbeitern. Die entsprechende Analyse findet sich bei Planet Mainframe.
Das bedeutet letztlich, dass wir zwei Probleme gleichzeitig lösen müssen. Wir müssen tiefes Plattformwissen erhalten und gleichzeitig verhindern, dass jeder Spezialist zum wandelnden Integrationspunkt für eine immer größere IT-Landschaft wird.
Ein Db2-Spezialist sollte Db2 außergewöhnlich gut verstehen. Er sollte aber nicht zusätzlich noch sämtliche Details eines Kubernetes-Clusters, eines Cloud-Security-Services, des API Gateways und jeder eingesetzten SaaS-Plattform auswendig kennen müssen, nur um herauszufinden, ob ein Produktionsproblem überhaupt in seinem Bereich liegt.
Genau hier können bessere Observability und automatisierte Korrelation einen echten Beitrag leisten.
Die interessanteste KI könnte deshalb zunächst gar nichts reparieren
Wenn heute über Agentic AI im IT-Betrieb gesprochen wird, entsteht schnell das Bild eines Systems, das Probleme erkennt und anschließend selbstständig behebt. Das klingt spektakulär, ist aber gerade in geschäftskritischen und regulierten Umgebungen möglicherweise nicht der sinnvollste erste Schritt.
Die Hanover-Untersuchung von Rocket Software liefert dazu einen interessanten Hinweis. Die Hälfte der befragten Finanzdienstleister nannte Anomalieerkennung und die Korrelation von Signalen über verschiedene Systeme hinweg als bevorzugten Einsatzbereich für agentische KI. Damit lag nicht die autonome Ausführung von Änderungen an erster Stelle, sondern zunächst das bessere Verständnis einer Situation.
Auch die 2026er BMC Mainframe Survey zeichnet ein eher pragmatisches Bild. BMC befragte weltweit mehr als 1.300 Mainframe-Praktiker und Entscheider und beschreibt eine zunehmende Präferenz für KI als Berater, der Auffälligkeiten erkennt und Maßnahmen empfiehlt, während Menschen die eigentliche Entscheidung und Ausführung kontrollieren. Die Ergebnisse sind in der BMC Mainframe Survey dokumentiert.
Das halte ich gerade für Mainframe Operations für eine sehr sinnvolle Reihenfolge.
Eine KI, die zehn verschiedene Telemetriequellen miteinander korreliert und einem Operator erklärt, dass drei scheinbar unabhängige Warnungen wahrscheinlich dieselbe Ursache haben, kann bereits enorm viel Zeit sparen. Sie muss dafür nicht automatisch eine CICS-Region stoppen, ein Db2-Paket rebinden oder eine Konfiguration verändern.
Vielleicht liegt der größere Nutzen zunächst darin, die Zeit zwischen Signal und Verständnis zu verkürzen.
Das verändert auch den Begriff „Erfahrung“
Traditionell entsteht operative Erfahrung dadurch, dass jemand viele reale Situationen erlebt. Nach dem zehnten vergleichbaren Produktionsproblem erkennt ein Spezialist Muster, die ein neuer Kollege schlicht noch nicht kennen kann.
Genau diese Erfahrung bleibt wertvoll. Gleichzeitig eröffnet sich aber die Möglichkeit, einen Teil davon systematisch nutzbar zu machen.
Wenn Telemetrie standardisiert wird, frühere Incidents strukturiert vorliegen und Diagnosesysteme Zusammenhänge zwischen Logs, Traces, Metriken und Mainframe-Daten erkennen können, muss ein neuer Mitarbeiter nicht jeden Fehler erst selbst erlebt haben, bevor er sinnvoll damit umgehen kann.
Das bedeutet nicht, dass aus einem Einsteiger innerhalb einer Woche ein Senior-Systemprogrammierer wird. Es bedeutet lediglich, dass moderne Werkzeuge einen Teil der kognitiven Last übernehmen können, die heute vollständig beim Menschen liegt.
Eine KI kann beispielsweise darauf aufmerksam machen, dass sich gleichzeitig Response Time, Db2-Wartezeit und MQ-Verhalten verändert haben. Ob diese Korrelation fachlich plausibel ist und welche Maßnahme daraus folgt, bleibt weiterhin eine Aufgabe, bei der Erfahrung und Systemverständnis entscheidend sind.
Das ist aus meiner Sicht eine wesentlich realistischere Vorstellung von KI im Mainframe-Betrieb als die Idee eines vollständig autonomen Operators.
Für Banken und Versicherungen ist die Diagnosefrage besonders relevant
Dass die Hanover-Untersuchung speziell Banken und Finanzdienstleister betrachtet, macht ihre Ergebnisse nicht automatisch auf jede Branche übertragbar. Für genau diesen Bereich sind sie allerdings besonders interessant.
Banken und Versicherungen betreiben typischerweise große hybride Landschaften, in denen Mainframe-Transaktionen eng mit Distributed-Systemen, APIs, mobilen Anwendungen, Datenplattformen und zunehmend auch Cloud-Services verbunden sind. Gleichzeitig sind Ausfälle teuer, regulatorische Anforderungen hoch und Änderungen an Produktionssystemen entsprechend kontrolliert.
In einer solchen Umgebung ist eine falsche Diagnose nicht nur lästig. Sie kann dazu führen, dass das falsche Team unter Zeitdruck an der falschen Stelle eingreift.
Wenn eine Zahlung aufgrund eines externen Services langsamer wird, bringt es wenig, zunächst CICS zu optimieren. Wenn die Ursache tatsächlich in Db2 liegt, hilft ein zusätzliches Kubernetes-Dashboard ebenfalls nicht weiter.
Der Wert einer guten Observability-Landschaft besteht deshalb nicht darin, möglichst viele Daten zu sammeln. Entscheidend ist, aus diesen Daten schnell eine belastbare Aussage darüber ableiten zu können, wo innerhalb eines geschäftlichen Ablaufs eine Auffälligkeit entsteht.
Gerade unter regulatorischem Druck ist außerdem nachvollziehbar, warum viele Unternehmen bei KI im Betrieb weiterhin auf Human-in-the-loop setzen. Die BMC-Studie beschreibt genau diesen Trend zu KI-gestützten Empfehlungen bei weiterhin menschlicher Verantwortung.
Ausbildung muss deshalb breiter werden, ohne an Tiefe zu verlieren
Diese Entwicklung hat aus meiner Sicht auch Konsequenzen für die Ausbildung neuer Mainframe-Spezialisten.
Natürlich müssen Grundlagen weiterhin gelernt werden. Wer CICS administriert, muss CICS verstehen, und wer Db2 optimiert, braucht tiefes Wissen über Db2. Das lässt sich nicht durch ein allgemeines „Cloud-Verständnis“ ersetzen.
Zusätzlich sollten wir aber stärker vermitteln, wie eine moderne Geschäftstransaktion über Systemgrenzen hinweg funktioniert. Ein Nachwuchsspezialist sollte verstehen, was eine Trace-ID ist, wie APIs, Messaging und verteilte Services zusammenspielen und warum ein Fehler, der auf z/OS sichtbar wird, nicht zwangsläufig dort entstanden sein muss.
Genauso wichtig ist eine systematische Diagnosemethodik. Gute Problemlösung beginnt nicht mit einem zufällig ausgewählten Tool, sondern mit der Frage, welche Hypothesen sich aus den vorhandenen Signalen ableiten lassen und welche Daten diese Hypothesen bestätigen oder widerlegen können.
Das klingt weniger spektakulär als die nächste KI-Funktion, dürfte im Alltag aber wesentlich mehr bewirken.
Denn je komplexer Systeme werden, desto wichtiger wird strukturiertes Denken.
Vielleicht brauchen wir weniger Superhelden und bessere Sichtbarkeit
Lange Zeit funktionierte Mainframe-Betrieb auch deshalb so zuverlässig, weil einzelne Spezialisten über ein enorm tiefes Wissen ihrer Umgebung verfügten. In manchen Unternehmen gibt es Menschen, die nach wenigen Symptomen ziemlich genau wissen, welche Logs sie ansehen müssen und welche scheinbar unbedeutende Änderung wahrscheinlich die Ursache war.
Solche Experten sind unbezahlbar.
Sie sind aber kein skalierbares Betriebsmodell.
Wenn eine Architektur so komplex wird, dass nur noch drei Menschen im Unternehmen verstehen, wie eine bestimmte Transaktion vollständig funktioniert, entsteht unabhängig vom Alter dieser Personen ein Risiko. Dieses Risiko lässt sich nicht allein durch mehr Schulungen beheben, wenn die zugrunde liegende technische Landschaft weiterhin unnötig schwer zu durchschauen ist.
Deshalb sollten Skills-Strategie und Architekturstrategie stärker zusammengedacht werden.
OpenTelemetry kann Systemgrenzen sichtbarer machen. Gute Observability kann Informationen aus mehreren Plattformen zusammenführen. KI kann helfen, große Mengen von Signalen zu korrelieren und Auffälligkeiten schneller hervorzuheben. Gleichzeitig bleiben SMF, CICS Monitoring, Db2 Accounting und das Wissen erfahrener Spezialisten unverzichtbar, wenn aus einer Auffälligkeit eine belastbare technische Diagnose werden soll.
Keines dieser Elemente löst das Problem allein.
In Kombination können sie aber dafür sorgen, dass ein Spezialist seine Zeit weniger damit verbringt, fünf unterschiedliche Welten manuell miteinander zu verbinden, und mehr damit, das eigentliche Problem zu lösen.
Der nächste Skills Gap sieht deshalb anders aus als der letzte
Der klassische Mainframe-Skills-Gap wird uns weiter beschäftigen. Unternehmen müssen Wissen erhalten, Nachwuchs aufbauen und dafür sorgen, dass Erfahrungen nicht gemeinsam mit ausscheidenden Mitarbeitern verschwinden.
Darüber hinaus entsteht jedoch eine zweite Herausforderung. Die Systeme, die diese Spezialisten betreiben, werden immer stärker miteinander verbunden, und damit verändert sich auch das Wissen, das im Störungsfall benötigt wird.
Der Mainframe-Spezialist der Zukunft muss deshalb nicht zwangsläufig jedes Cloud-Produkt beherrschen. Er benötigt aber eine Umgebung, in der Zusammenhänge über Plattformgrenzen hinweg sichtbar werden. Umgekehrt müssen Distributed- und Cloud-Teams erkennen können, welchen Anteil der Mainframe an einer Transaktion hat, ohne dafür zunächst selbst zu z/OS-Spezialisten werden zu müssen.
Genau darin liegt für mich der entscheidende Punkt: Der Skills Gap lässt sich nicht ausschließlich dadurch lösen, dass wir mehr Wissen in einzelne Köpfe packen. Wir sollten gleichzeitig dafür sorgen, dass unsere Systeme leichter verständlich und besser beobachtbar werden.
Vielleicht fehlt uns in Zukunft deshalb nicht nur jemand, der z/OS versteht.
Problematisch wird es vor allem dann, wenn niemand mehr ohne tagelange Detektivarbeit erkennen kann, wie z/OS, Cloud, APIs, Distributed Systems und externe Services gemeinsam einen einzigen Geschäftsprozess bilden.
Und genau deshalb könnte die wichtigste Fähigkeit im nächsten Produktionsproblem weniger darin bestehen, einen bestimmten Befehl auswendig zu kennen.
Sie könnte darin bestehen, aus sehr vielen technischen Signalen schnell genug zu erkennen, welche davon tatsächlich 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
