Wer als CIO einer Bank über Mainframe-Modernisierung spricht, beschäftigt sich in der Regel mit anderen Fragen als mit der Wahl eines Editors oder eines Konfigurationsformats. Im Vordergrund stehen Verfügbarkeit, regulatorische Anforderungen, Cyber Resilience, Kosten, Fachkräfte und vor allem die Fähigkeit, geschäftskritische Systeme auch in zehn Jahren noch sicher betreiben und weiterentwickeln zu können. Genau aus dieser Perspektive lohnt sich ein genauerer Blick auf IBM Project Polaris.
IBM bezeichnet Polaris als „Next Generation z/OS Experience“. Auf den ersten Blick klingt das nach einer modernisierten Benutzeroberfläche oder nach dem Versuch, den Mainframe für eine jüngere Generation von Administratoren attraktiver zu machen. Die bisher vorgestellten Konzepte reichen jedoch deutlich weiter. IBM versucht, Arbeitsweisen rund um z/OS stärker an Verfahren anzunähern, die in anderen Bereichen der Unternehmens-IT längst selbstverständlich sind. Konfigurationen sollen nachvollziehbarer werden, Änderungen können versioniert werden, Automatisierung soll einfacher werden, standardisierte Schnittstellen sollen den Zugriff auf Systeminformationen erleichtern und KI soll Administratoren dabei unterstützen, Zusammenhänge schneller zu verstehen.
Für Banken berührt Polaris damit eine grundsätzliche strategische Frage: Wie kann eine hochkritische, über Jahrzehnte gewachsene Plattform so weiterentwickelt werden, dass ihre Zuverlässigkeit erhalten bleibt und ihr Betrieb gleichzeitig weniger stark vom Wissen einzelner Spezialisten abhängt?
Der Mainframe bleibt Teil der Bankeninfrastruktur
Die Diskussion über Mainframes leidet seit Jahren unter einem merkwürdigen Widerspruch. Einerseits werden sie regelmäßig als Legacy-Technologie bezeichnet, andererseits betreiben Banken darauf weiterhin einige ihrer wichtigsten Geschäftsprozesse. Kontoführung, Zahlungsverkehr, Wertpapierverarbeitung, Kreditprozesse oder große Bestandsanwendungen lassen sich nicht nach Belieben austauschen, denn die dahinterliegenden Systeme wurden über viele Jahre optimiert, integriert und an regulatorische Anforderungen angepasst.
Dass IBM Z in diesem Umfeld weiterhin eine Rolle spielt, lässt sich auch an aktuellen Investitionsentscheidungen erkennen. IBM berichtete beispielsweise Anfang 2026 über die Fortsetzung der Zusammenarbeit mit der Commerzbank und die weitere Modernisierung ihrer Kernbankeninfrastruktur auf Basis von IBM Z und IBM Storage.
Für viele Finanzunternehmen stellt sich deshalb längst weniger die Frage, ob morgen noch ein Mainframe vorhanden sein wird. Wichtiger ist, wie eine Plattform, die noch viele Jahre geschäftskritische Aufgaben übernehmen dürfte, organisatorisch und technologisch in eine moderne IT-Landschaft eingebunden werden kann. Genau an diesem Punkt wird Polaris interessant.
Wenn Betriebswissen zum Risikofaktor wird
Mainframes genießen zu Recht einen Ruf für außergewöhnliche Stabilität. Weniger sichtbar ist der organisatorische Aufwand, der hinter dieser Stabilität steckt. Viele z/OS-Umgebungen sind über Jahrzehnte gewachsen, ihre Konfiguration folgt etablierten Verfahren und ihre Administratoren verfügen häufig über ein enormes Wissen darüber, wie einzelne Einstellungen, Produkte und Abhängigkeiten zusammenspielen.
Ein erheblicher Teil dieses Wissens lässt sich dokumentieren, ein anderer Teil entsteht erst durch langjährige Erfahrung. Der erfahrene Systemprogrammierer weiß, welche Einstellung besser unangetastet bleibt, welche Änderung Auswirkungen auf andere Komponenten haben könnte und an welcher Stelle man suchen sollte, wenn sich ein System plötzlich anders verhält. Häufig kennt er auch die Geschichte einer Umgebung und weiß, warum eine bestimmte Konfiguration vor vielen Jahren eingeführt wurde oder weshalb eine scheinbar überflüssige Einstellung weiterhin gebraucht wird.
Für die Unternehmensführung entsteht daraus dann ein strukturelles Risiko, wenn zu viel von diesem Wissen an einzelne Personen gebunden ist. IBM nennt im Zusammenhang mit Polaris selbst eine bemerkenswerte Größenordnung. Nach Einschätzung des Unternehmens kann es heute zwei bis sechs Jahre dauern, bis ein neuer z/OS-Systemprogrammierer volle Kompetenz erreicht. Mit der neuen z/OS Experience möchte IBM diese Zeit perspektivisch auf zwei bis sechs Monate reduzieren. Diese Größenordnung ist ein Entwicklungsziel und bislang kein nachgewiesener Produktivitätseffekt, sie zeigt aber deutlich, wie groß IBM die Herausforderung selbst einschätzt.
Für einen CIO ist diese Aussage vor allem deshalb relevant, weil Wissenstransfer damit unmittelbar in den Bereich des operationellen Risikomanagements rückt. Wenn eine geschäftskritische Infrastruktur mehrere Jahre Einarbeitung benötigt, bevor neue Mitarbeiter sie weitgehend selbstständig administrieren können, betrifft das Personalplanung, Resilienz und Zukunftsfähigkeit gleichermaßen.
Konfiguration wird nachvollziehbarer
Eine der Grundlagen von Polaris ist „Configuration as Code“. Hinter diesem Begriff steckt ein Ansatz, der außerhalb des Mainframes längst weit verbreitet ist: Die Konfiguration eines Systems wird als kontrolliertes digitales Artefakt behandelt, das versioniert, geprüft und nachvollziehbar verändert werden kann.
Änderungen lassen sich dadurch vergleichen, es wird transparenter, wer etwas verändert hat, welche Einstellungen zuvor galten und was anschließend anders ist. Prüfungen können automatisiert werden, bevor eine Konfiguration eingesetzt wird. IBM nennt für Polaris unter anderem YAML-basierte Konfiguration, Git, integrierte Validierung und eine transparente Darstellung geplanter Änderungen.
Für einen CIO ist dabei zweitrangig, wie das zugrunde liegende Dateiformat heißt. Wichtiger ist, dass sich ein Teil des Betriebswissens, das heute in Dokumentationen, Procedures und den Köpfen erfahrener Mitarbeiter steckt, strukturierter abbilden lässt. Änderungen hinterlassen eine Historie, Unterschiede zwischen Umgebungen werden leichter sichtbar und automatisierte Prüfungen können Fehler frühzeitig erkennen.
Damit nähert sich die Administration einer geschäftskritischen Infrastruktur stärker den Governance-Prinzipien an, die Unternehmen aus der Softwareentwicklung bereits kennen. Für Banken kann daraus ein erheblicher Vorteil entstehen, weil technische Änderungen besser dokumentierbar und kontrollierbarer werden.
DORA verleiht dieser Entwicklung zusätzliche Bedeutung
Seit dem 17. Januar 2025 gilt in der Europäischen Union der Digital Operational Resilience Act, kurz DORA. Für Banken und andere Finanzunternehmen sind damit Anforderungen an die digitale operationale Resilienz verbindlicher und einheitlicher geworden.
DORA verlangt unter anderem dokumentierte Verfahren für Änderungen an IKT-Systemen. Änderungen sollen erfasst, getestet, bewertet, genehmigt, implementiert und anschließend kontrolliert verifiziert werden. Die dazugehörigen technischen Regulierungsstandards konkretisieren diese Anforderungen weiter und verlangen unter anderem klar definierte Rollen und Verantwortlichkeiten sowie eine angemessene Trennung von Beantragung, Genehmigung und Umsetzung von Änderungen.
Project Polaris macht eine Bank selbstverständlich nicht DORA-konform. Governance, Verantwortlichkeiten und funktionierende Kontrollprozesse müssen weiterhin organisatorisch geregelt werden. Die Architekturidee von Polaris passt jedoch auffällig gut zu einer Umgebung, in der Veränderungen nachvollziehbar, reproduzierbar und kontrolliert durchgeführt werden müssen.
Wenn Konfigurationen versioniert vorliegen, Änderungen eindeutig sichtbar sind und technische Prüfungen bereits vor einer Umsetzung erfolgen können, entsteht eine bessere Grundlage für geregelte Change-Prozesse. Der technische Zustand eines Systems lässt sich dadurch enger mit den organisatorischen Prozessen verbinden, die diesen Zustand genehmigt haben. Für die Finanzwirtschaft ist das weit mehr als eine Verbesserung der Bedienung.
Erfahrungswissen lässt sich besser in Prozesse überführen
In vielen Unternehmen basiert zuverlässiger Mainframe-Betrieb auf einer Kombination aus hervorragender Technik, etablierten Verfahren und sehr erfahrenen Menschen. Über Jahrzehnte hat diese Kombination ausgesprochen gut funktioniert. Die personelle Situation verändert sich jedoch, weil erfahrene Spezialisten in den Ruhestand gehen und neue Mitarbeiter in eine Systemlandschaft kommen, deren technische Geschichte teilweise älter ist als sie selbst.
Gleichzeitig wachsen Mainframe-, Cloud- und Distributed-Welten immer stärker zusammen. Damit steigt der Umfang des Wissens, das benötigt wird, um technische Änderungen sicher einschätzen zu können. Unternehmen reagieren darauf häufig mit zusätzlicher Dokumentation, doch Dokumentation allein löst das Problem nur teilweise. Sie altert, technische Zusammenhänge verändern sich und vieles, was ein erfahrener Administrator intuitiv berücksichtigt, findet niemals den Weg in ein Handbuch.
Ein stärker strukturierter, versionierter und automatisierter Betrieb eröffnet hier zusätzliche Möglichkeiten. Wissen kann zunehmend in Prozesse, Regeln, Prüfungen und technische Artefakte einfließen. Ein erfahrener Spezialist definiert beispielsweise, unter welchen Bedingungen eine Änderung zulässig ist, und diese Prüfung kann anschließend Bestandteil eines standardisierten Ablaufs werden. Neue Mitarbeiter profitieren dadurch von Erfahrungswissen, ohne jede Situation zunächst selbst mehrfach erlebt haben zu müssen.
Erfahrung verliert dadurch keineswegs an Bedeutung. Sie kann vielmehr wirksamer im Unternehmen verankert und über einzelne Personen hinaus nutzbar gemacht werden. Für CIOs, die in den kommenden Jahren größere altersbedingte Personalwechsel bewältigen müssen, ist dieser Aspekt vermutlich deutlich relevanter als die Diskussion über neue Benutzeroberflächen.
KI als Unterstützung im täglichen Betrieb
Polaris enthält auch KI-Funktionen. IBM integriert watsonx Assistant for Z und entwickelt Möglichkeiten, über die ein Assistent Informationen über den aktuellen Systemkontext erhalten kann. Administratoren sollen damit Fragen zu einer Umgebung stellen und Unterstützung bei Konfiguration und Analyse erhalten können. IBM beschreibt den Ansatz als kontextbezogene Unterstützung direkt innerhalb der z/OS-Arbeitsumgebung.
Für Banken ist eine solche Funktion zwangsläufig mit Governance-Fragen verbunden. Es muss geklärt werden, welche Systeminformationen ein Assistent auswerten darf, welche Aktionen er vorbereiten kann, welche davon tatsächlich ausgeführt werden dürfen und wie Berechtigungen berücksichtigt werden. Ebenso relevant ist die Frage, wie KI-gestützte Empfehlungen dokumentiert werden und an welcher Stelle ein Mensch ausdrücklich zustimmen muss.
Trotz dieser offenen Punkte ist die Richtung interessant. Ein neuer Systemprogrammierer könnte schneller verstehen, warum eine bestimmte Einstellung existiert, welche Komponenten davon betroffen sind und welche Dokumentation dafür relevant ist. Ein erfahrener Mitarbeiter könnte wiederum bei Analyse und Recherche entlastet werden.
Der praktische Nutzen entsteht vor allem dann, wenn vorhandenes Fachwissen, aktueller Systemkontext und kontrollierte Arbeitsabläufe zusammengeführt werden. Für eine Bank dürfte eine KI, die erfahrene Systemprogrammierer schneller zu belastbaren Entscheidungen bringt, deutlich wertvoller sein als eine spektakuläre Demonstration autonomer Administration.
z/OS lässt sich besser in die Gesamtsteuerung der IT einbinden
Project Polaris könnte außerdem dazu beitragen, dass der Mainframe organisatorisch näher an andere Bereiche der Unternehmens-IT rückt. Die Mainframe-Welt verfügt über viele hervorragend funktionierende Verfahren, die außerhalb des Mainframe-Teams jedoch kaum bekannt sind. Gleichzeitig verwendet die übrige Unternehmens-IT längst Git-basierte Prozesse, APIs, Automatisierungsplattformen, Infrastructure as Code und übergreifende Governance-Werkzeuge.
Je stärker z/OS solche Arbeitsweisen unterstützt, desto einfacher lässt sich die Plattform in eine gemeinsame Betriebs- und Steuerungsarchitektur integrieren. Für einen CIO kann das erheblich sein, weil eine vollständig separate Betriebslogik organisatorisch dauerhaft zusätzliche Komplexität erzeugt.
Wenn sich gemeinsame Prinzipien für Change Management, Automatisierung, Versionierung und Schnittstellen verwenden lassen, werden zumindest Teile dieser Grenze durchlässiger. Ein Enterprise-Architecture-Team kann ähnliche Governance-Prinzipien anwenden, ein Security-Team erhält standardisiertere Zugänge zu Informationen und Automatisierungsplattformen können über definierte Schnittstellen angebunden werden. Neue Mitarbeiter treffen gleichzeitig auf Werkzeuge und Vorgehensweisen, die sie bereits aus anderen Bereichen der IT kennen.
z/OS bleibt dabei selbstverständlich z/OS. Seine Besonderheiten verschwinden nicht und sind bei vielen geschäftskritischen Workloads gerade der Grund für seinen Einsatz. Eine gemeinsame methodische Basis kann die Zusammenarbeit zwischen Mainframe- und Nicht-Mainframe-Teams jedoch deutlich erleichtern.
Modernisierung betrifft auch den Betrieb
Mainframe-Strategien werden häufig in Extremen diskutiert. Auf der einen Seite steht der vollständige Erhalt bestehender Systeme, auf der anderen eine möglichst weitgehende Migration auf neue Plattformen. Die Realität großer Banken sieht erheblich differenzierter aus.
Einige Anwendungen werden modernisiert, andere ersetzt. Neue Services entstehen außerhalb des Mainframes und greifen weiterhin auf bestehende Kernsysteme zu. APIs verbinden neue und alte Welten. Java, COBOL und andere Technologien existieren nebeneinander, während Cloud-Plattformen zusätzliche Aufgaben übernehmen und hochvolumige Transaktionen weiterhin auf IBM Z verarbeitet werden.
Eine solche Landschaft kann noch sehr lange bestehen. Deshalb gewinnt die Modernisierung des Betriebs eine ähnliche Bedeutung wie die Modernisierung der Anwendungen. Ein Unternehmen, das seine Anwendungen modernisiert, dessen zugrunde liegende Infrastruktur aber weiterhin ausschließlich mit schwer übertragbarem Expertenwissen betrieben werden kann, hat einen wesentlichen Teil seiner langfristigen Herausforderung noch vor sich.
Project Polaris setzt genau an dieser häufig weniger sichtbaren Seite der Modernisierung an.
Polaris ist noch nicht am Ziel
Bei aller strategischen Bedeutung sollte der heutige Reifegrad realistisch eingeschätzt werden. IBM Project Polaris befindet sich 2026 noch im Technology-Preview-Umfeld. IBM spricht von einem zunächst begrenzten privaten Programm und plant eine breitere Verfügbarkeit. Funktionen können sich bis zu einem späteren Produktstatus verändern.
Für Banken wäre es deshalb verfrüht, Polaris bereits als Grundlage eines konkreten Transformationsprogramms einzuplanen. Die Initiative eignet sich aber sehr gut als Anlass, die eigene Situation zu überprüfen.
Wie lange dauert es heute, einen neuen z/OS-Systemprogrammierer produktiv zu machen? Wie viel betriebliches Wissen ist tatsächlich dokumentiert? Wie viele kritische Verfahren hängen von wenigen erfahrenen Mitarbeitern ab? Wie nachvollziehbar sind Konfigurationsänderungen über mehrere Jahre hinweg? Wie einfach lässt sich feststellen, warum sich zwei Systemumgebungen voneinander unterscheiden? Und wie gut passen Mainframe-Changes in die unternehmensweiten Governance- und Automatisierungsprozesse?
Diese Fragen bleiben relevant, unabhängig davon, wann Polaris allgemein verfügbar wird.
Warum CIOs Polaris schon heute beobachten sollten
IBM hat in den vergangenen Jahren viel dafür getan, moderne Softwareentwicklung auf dem Mainframe zugänglicher zu machen. Git, moderne IDEs, APIs, DevOps-Verfahren und automatisierte Pipelines gehören inzwischen zur Realität vieler z/OS-Entwicklungsteams. Mit Polaris erreicht diese Entwicklung zunehmend auch den Betrieb der Plattform selbst.
Für Banken kommt das zu einem Zeitpunkt, an dem mehrere Entwicklungen gleichzeitig zusammenlaufen. Der Mainframe bleibt für viele Institute ein wichtiger Bestandteil ihrer Kerninfrastruktur, während erfahrene Spezialisten altersbedingt ausscheiden, regulatorische Anforderungen an Nachvollziehbarkeit und Resilienz wachsen und der Druck zur Automatisierung weiter zunimmt.
Damit verändert sich auch die Frage, was unter Mainframe-Modernisierung verstanden werden sollte. Anwendungen, Schnittstellen und Entwicklungswerkzeuge sind nur ein Teil davon. Ebenso wichtig ist die Fähigkeit, das Wissen über die Plattform dauerhaft im Unternehmen zu halten und den Betrieb so zu organisieren, dass neue Mitarbeiter schneller Verantwortung übernehmen können.
Genau hier könnte Polaris langfristig Wirkung entfalten. Wenn Konfigurationen nachvollziehbar versioniert werden, Prüfungen automatisiert ablaufen und Wissen stärker in kontrollierte Prozesse einfließt, wird aus persönlicher Erfahrung schrittweise ein organisatorisch nutzbarer Wissensbestand.
Für Banken wäre das ein erheblicher Fortschritt. Die Stabilität des Mainframes beruht seit Jahrzehnten auf einer Kombination aus ausgereifter Technik und hochqualifizierten Menschen. Die kommenden Jahre werden zeigen, ob IBM mit Polaris einen Weg findet, einen größeren Teil dieses Wissens so im Betrieb zu verankern, dass es leichter weitergegeben, überprüft und langfristig erhalten werden kann.
Ü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
