Ein Beitrag von Uwe Graf, Head of Consulting bei EasiRun.
Wer seit vielen Jahren mit z/OS arbeitet, kennt eine Besonderheit der Plattform: Viele Aufgaben lassen sich außerordentlich zuverlässig erledigen, setzen aber ein beträchtliches Maß an Erfahrung voraus. PARMLIB-Strukturen, unterschiedliche Kommandowelten, TSO, ISPF, UNIX System Services, Operator Commands und zahlreiche produktspezifische Verfahren sind über Jahrzehnte entstanden und bilden heute eine leistungsfähige, zugleich aber anspruchsvolle Betriebsumgebung.
Mit IBM Project Polaris versucht IBM, diese Umgebung schrittweise zugänglicher zu machen. Das Projekt wird als „Next Generation z/OS Experience“ entwickelt und befindet sich derzeit im Technology-Preview-Umfeld. IBM nennt inzwischen vier technische Säulen, auf denen diese neue Erfahrung aufbauen soll: Configuration as Code, AI Assistance, eine API-first Architecture und eine modernisierte Command Line Interface.
Die einzelnen Technologien sind für sich genommen kaum überraschend. YAML, Git, APIs, SSH und KI-Assistenten gehören in vielen Bereichen der IT längst zum Alltag. Spannend wird Polaris durch die Frage, wie konsequent IBM diese Arbeitsweisen auf die Administration von z/OS übertragen kann und welche Veränderungen daraus für Systemprogrammierer entstehen.
Warum z/OS-Konfiguration ein guter Ausgangspunkt ist
IBM hat sich für die ersten Polaris-Schritte bewusst auf die Systemkonfiguration konzentriert. Das erscheint sinnvoll, weil sich hier sehr gut erkennen lässt, wo die Unterschiede zwischen einer klassischen z/OS-Administration und heutigen Infrastructure-as-Code-Verfahren liegen.
Viele z/OS-Konfigurationen befinden sich traditionell in PARMLIB-Membern und weiteren plattformspezifischen Strukturen. Für erfahrene Systemprogrammierer ist das vertrautes Terrain. Wer aus einer Linux-, Cloud- oder DevOps-Umgebung kommt, trifft dagegen auf Konzepte, Syntax und Werkzeuge, die zunächst erlernt werden müssen.
IBM beziffert den Zeitraum, den ein neuer z/OS-Systemprogrammierer bis zur umfassenden Beherrschung der Plattform benötigen kann, heute auf zwei bis sechs Jahre. Mit der neuen z/OS Experience verfolgt das Unternehmen das ambitionierte Ziel, diesen Zeitraum perspektivisch auf zwei bis sechs Monate zu verkürzen. Diese Größenordnung beschreibt derzeit ein Entwicklungsziel und sollte deshalb noch nicht als nachgewiesener Produktivitätsgewinn verstanden werden. IBM verweist allerdings darauf, dass die Polaris-Arbeiten auf dem Austausch mit mehr als 200 Systemprogrammierern aus Kundenumgebungen beruhen.
Die Konfiguration eignet sich für einen solchen Ansatz besonders gut, weil sich dort viele Tätigkeiten wiederholen und Änderungen häufig nach festen Regeln vorgenommen werden. Gleichzeitig können Fehler erhebliche Auswirkungen haben. Genau deshalb spielen Nachvollziehbarkeit, Validierung und kontrollierte Änderungen eine so große Rolle.
Configuration as Code erreicht z/OS
Der technisch wahrscheinlich sichtbarste Bestandteil von Polaris ist die YAML-basierte Configuration as Code. IBM möchte ausgewählte z/OS-Konfigurationen in einer Form darstellen, die mit Werkzeugen bearbeitet werden kann, die Entwickler und Administratoren aus anderen Plattformen bereits kennen.
Im aktuellen Technology-Preview-Ansatz werden Konfigurationen als YAML-Dateien dargestellt und in Git verwaltet. Die Bearbeitung kann beispielsweise in Visual Studio Code erfolgen. Schemas ermöglichen dort eine Validierung, bevor eine Änderung tatsächlich auf das Zielsystem gelangt. Änderungen werden versioniert und ihre Historie bleibt nachvollziehbar. IBM nennt außerdem ausdrücklich die Möglichkeit, Konfigurationsunterschiede zwischen Systemen sichtbar zu machen.
Damit entsteht ein Arbeitsmodell, das sich vereinfacht folgendermaßen darstellen lässt:
Für Mainframe-Teams ist daran vor allem die Verbindung mit etablierten Verfahren interessant. Eine Änderung an einer Systemkonfiguration kann künftig wesentlich stärker wie eine Änderung an Software behandelt werden. Git liefert eine Historie, Unterschiede zwischen Versionen lassen sich direkt vergleichen und Freigabeschritte können in bestehende Prozesse eingebunden werden.
Damit entsteht auch eine andere Grundlage für Automatisierung. Wenn eine Konfiguration in einem maschinenlesbaren und validierbaren Format vorliegt, können Pipelines damit arbeiten, Prüfungen automatisiert erfolgen und definierte Änderungen reproduzierbar ausgeführt werden.
IBM beginnt dabei bewusst mit einem begrenzten Umfang an PARMLIB-Membern. Die dazugehörigen Schemas werden nach IBM-Angaben gemeinsam mit den zuständigen z/OS-Komponententeams entwickelt. Weitere Konfigurationsbereiche sollen im Verlauf der Technology Preview hinzukommen.
Das ist ein wichtiger Punkt, denn eine vollständige Abbildung der z/OS-Konfiguration in YAML wäre ein erheblich größeres Vorhaben als eine neue Darstellungsform für einige Parameter. Der aktuelle Stand sollte deshalb als Beginn einer Entwicklung betrachtet werden.
Git könnte im Systembetrieb eine größere Rolle bekommen
Git wird im Mainframe-Umfeld inzwischen häufig für Anwendungsquellcode eingesetzt. Moderne Entwicklungsumgebungen und DevOps-Prozesse haben dazu beigetragen, dass COBOL-, Java- oder HLASM-Sourcen zunehmend in Git-Repositories verwaltet werden.
Polaris erweitert diesen Gedanken auf die Systemkonfiguration.
Das hat praktische Konsequenzen. Wenn beispielsweise eine SMF-Konfiguration angepasst wird, kann im Repository nachvollzogen werden, welche Einstellung geändert wurde, wer diese Änderung vorgenommen hat und wie der vorherige Zustand aussah. Eine geplante Änderung lässt sich vor der Umsetzung prüfen und mit anderen Beteiligten abstimmen.
Gerade bei mehreren LPARs und unterschiedlichen Entwicklungs-, Test- und Produktionsumgebungen eröffnet dies interessante Möglichkeiten. Configuration Drift wird leichter sichtbar, weil Konfigurationen maschinell miteinander verglichen werden können. Aus der Frage „Warum verhält sich dieses System anders?“ kann damit sehr viel schneller die konkrete Frage werden, welche Konfigurationen voneinander abweichen.
Für erfahrene Systemprogrammierer ersetzt das keine Analyse. Es verkürzt jedoch möglicherweise einen Teil der Suche, die heute erforderlich ist, bevor die eigentliche technische Bewertung beginnen kann.
Validierung vor der Änderung
Ein weiterer Aspekt dürfte im täglichen Betrieb mindestens ebenso wichtig sein wie Git. Polaris sieht vor, Konfigurationsänderungen bereits während der Bearbeitung gegen definierte Schemas zu prüfen.
Das verändert den Zeitpunkt, an dem bestimmte Fehler erkannt werden können.
Bei einer klassischen Konfigurationsänderung wird ein Fehler unter Umständen erst sichtbar, wenn ein Member ausgewertet oder eine betreffende Komponente gestartet beziehungsweise neu konfiguriert wird. Eine schemaunterstützte Umgebung kann zumindest einen Teil syntaktischer und struktureller Fehler früher erkennen.
Dabei sollte man die Erwartungen realistisch halten. Eine technisch gültige Konfiguration ist selbstverständlich noch keine fachlich oder betrieblich sinnvolle Konfiguration. Abhängigkeiten zwischen Komponenten, besondere Installationsanforderungen und lokale Betriebsstandards bleiben weiterhin relevant.
Trotzdem verbessert eine frühzeitige Validierung die Ausgangslage. Fehler, die sich zuverlässig maschinell erkennen lassen, müssen nicht erst durch einen Systemprogrammierer gefunden werden. Dessen Zeit steht damit stärker für die Prüfung der Zusammenhänge zur Verfügung, bei denen Erfahrung tatsächlich gebraucht wird.
API-first schafft eine gemeinsame technische Grundlage
Weniger sichtbar als YAML und Git, langfristig möglicherweise aber besonders weitreichend, ist die API-first-Strategie von Polaris.
IBM arbeitet an einem gemeinsamen Satz von z/OS-APIs, über die Informationen zum aktuellen Systemzustand zugänglich werden sollen. Die technische Basis bilden nach Angaben von IBM native 64-Bit-C-APIs unter z/OS UNIX System Services. Auf dieser Grundlage können weitere Sprachbindungen, CLI-Funktionen und Werkzeuge aufgebaut werden.
Die Architektur lässt sich vereinfacht so darstellen:
↓
gemeinsame APIs
↓
CLI | Portal | Automation | MCP | weitere Werkzeuge
Für die weitere Entwicklung ist dieser Ansatz wichtig, weil nicht jede neue Bedienoberfläche einen eigenen Zugang zu z/OS implementieren muss. Wenn die zugrunde liegende API-Abdeckung wächst, können verschiedene Werkzeuge dieselben Funktionen nutzen.
Das bietet auch Möglichkeiten für Unternehmen, die ihre Mainframe-Umgebung stärker in bestehende Automatisierungs- und Betriebsplattformen integrieren wollen. Standardisierte Schnittstellen erleichtern die Anbindung an übergreifende Prozesse, weil Informationen nicht für jedes Werkzeug über einen eigenen technischen Weg beschafft werden müssen.
Wie umfassend diese API-Landschaft am Ende wird, lässt sich während einer Technology Preview noch nicht seriös beurteilen. Die Architekturentscheidung selbst ist dennoch bemerkenswert, weil sie weit über eine neue grafische Oberfläche hinausweist.
Die Kommandozeile soll vertrauter werden
Auch die Command Line Interface spielt in Polaris eine wichtige Rolle. IBM verfolgt langfristig das Ziel, typische z/OS-Aufgaben stärker über eine UNIX-orientierte Kommandozeile zugänglich zu machen.
Die Vorstellung ist relativ einfach: Ein Administrator meldet sich per SSH an und arbeitet über vertraute Shell-Konzepte mit dem System. Konfigurationen sollen untersucht, Systemzustände abgefragt und operative Funktionen zunehmend aus dieser Umgebung heraus genutzt werden können.
Heute wechseln z/OS-Systemprogrammierer abhängig von der Aufgabe zwischen verschiedenen Welten. UNIX System Services, TSO, ISPF, Operator Commands und produktspezifische Werkzeuge gehören zum normalen Arbeitsalltag. Diese Vielfalt ist historisch gewachsen und bildet unterschiedliche Funktionen der Plattform ab, erhöht für neue Mitarbeiter jedoch die Einstiegshürde.
Eine modernisierte CLI könnte dabei helfen, zumindest einen Teil dieser Tätigkeiten über eine gemeinsame Interaktionsform zugänglich zu machen. Für Administratoren mit Linux-Erfahrung sinkt damit die Zahl der Konzepte, die sie erlernen müssen, bevor sie erste Aufgaben selbstständig bearbeiten können.
Erfahrene z/OS-Spezialisten werden ihre bestehenden Werkzeuge deshalb kaum sofort aufgeben. Das ist auch gar nicht erforderlich. Interessant ist vielmehr, dass künftig mehrere Zugangswege auf dieselben technischen Grundlagen zurückgreifen könnten.
KI bekommt Zugriff auf den Systemkontext
Die AI-Komponente von Polaris basiert auf IBM watsonx Assistant for Z und wird in die neue z/OS-Erfahrung integriert. Interessanter als die Chat-Oberfläche selbst ist die technische Verbindung zwischen Assistent und System.
IBM liefert dafür im Rahmen der Technology Preview einen MCP Server auf z/OS. MCP steht für Model Context Protocol. Über diesen Server kann der Assistent auf Informationen über den aktuellen Systemzustand zugreifen. IBM beschreibt beispielsweise ein Szenario, in dem ein Benutzer nach der aktiven SMF-Konfiguration eines Systems fragt. Der Assistent kann dazu Systeminformationen abrufen und seine Antwort mit dem konkreten Kontext der Umgebung verbinden.
Damit verändert sich die Qualität einer solchen Unterstützung erheblich.
Eine allgemeine Frage zu SMF kann heute bereits jedes gut trainierte Sprachmodell beantworten. Für einen Systemprogrammierer wird Unterstützung wesentlich interessanter, wenn sich die Antwort auf das tatsächlich konfigurierte System bezieht und mit dessen Zustand verknüpft werden kann.
IBM plant zudem, die über MCP verfügbaren Werkzeuge unabhängig vom grundlegenden z/OS-Release-Zyklus erweitern zu können. Als spätere Anwendungsfelder nennt das Unternehmen unter anderem Upgrades, Impact Analysis und die Erkennung von Configuration Drift. Dabei spricht IBM ausdrücklich von Guardrails und einer menschlichen Kontrolle bei weitergehender Automatisierung.
Gerade dieser Punkt dürfte für den produktiven Einsatz entscheidend werden. Ein Assistent, der Informationen sammelt, Zusammenhänge erklärt und einen Änderungsvorschlag vorbereitet, lässt sich organisatorisch wesentlich einfacher beherrschen als ein autonomes System, das selbstständig Änderungen an einer produktiven z/OS-Umgebung durchführt.
Ein Beispiel: SMF-Konfiguration
Wie die einzelnen Polaris-Bausteine zusammenspielen können, lässt sich gut am Beispiel einer SMF-Konfiguration verdeutlichen.
Ein neuer Systemprogrammierer soll eine bestimmte Form des Monitorings aktivieren und kennt die dazu notwendigen Einstellungen noch nicht vollständig. In einer klassischen Umgebung würde er zunächst die relevante Dokumentation suchen, die betreffenden PARMLIB-Member identifizieren, die vorhandene Konfiguration untersuchen und anschließend eine Änderung vorbereiten.
Im Polaris-Modell kann ein Teil dieser Arbeit stärker zusammengeführt werden. Der AI Assistant hilft bei der fachlichen Orientierung und kann über den MCP Server Informationen zum aktuellen Systemzustand einbeziehen. Die betreffende Konfiguration wird in einer strukturierten Form dargestellt, eine geplante Änderung kann validiert und anschließend über Git nachvollziehbar verwaltet werden.
Der Ablauf könnte damit ungefähr folgendermaßen aussehen:
↓
Systemzustand ermitteln
↓
kontextbezogene Unterstützung
↓
Konfiguration bearbeiten
↓
Schema-Validierung
↓
Git / Review
↓
kontrollierte Umsetzung
Die Verantwortung für die Änderung bleibt dabei bei den zuständigen Personen und Prozessen. Der technische Ablauf kann jedoch wesentlich mehr Informationen zusammenführen und einen größeren Teil der wiederkehrenden Arbeit absichern.
Was sich für erfahrene Systemprogrammierer verändert
Polaris wird häufig im Zusammenhang mit neuen Mitarbeitern und dem Mainframe-Skills-Gap diskutiert. Das ist nachvollziehbar, beschreibt aber nur einen Teil des möglichen Nutzens.
Auch erfahrene Systemprogrammierer verbringen einen beträchtlichen Teil ihrer Zeit mit Tätigkeiten, die sich zumindest teilweise standardisieren lassen. Dazu gehören die Recherche in umfangreicher Dokumentation, der Vergleich von Systemen, die Prüfung von Konfigurationen oder das Nachvollziehen früherer Änderungen.
Wenn Polaris solche Aufgaben vereinfacht, kann dies den Arbeitsalltag erfahrener Spezialisten ebenfalls verändern. Ihr Wissen wird weiterhin gebraucht, kann aber stärker dort eingesetzt werden, wo technische Zusammenhänge bewertet und Entscheidungen getroffen werden müssen.
Besonders interessant wird dieser Gedanke beim Wissenstransfer. Ein Teil des Erfahrungswissens kann in Konfigurationsregeln, Validierungen, dokumentierte Änderungen und automatisierte Prüfungen einfließen. Neue Mitarbeiter arbeiten damit in einer Umgebung, die einen Teil der über Jahre aufgebauten Erfahrung bereits strukturell enthält.
Das dürfte realistischer sein als die Erwartung, einen erfahrenen Systemprogrammierer durch einen KI-Assistenten ersetzen zu können.
Polaris passt zu einer breiteren Entwicklung auf IBM Z
Project Polaris steht außerdem nicht isoliert. IBM verfolgt parallel verschiedene Ansätze, um IBM Z stärker über APIs, Automatisierung und Infrastructure as Code in moderne Betriebsmodelle einzubinden.
In einem Update vom September 2026 ordnet IBM Polaris ausdrücklich in eine Strategie ein, die auf automatisiertere und AI-unterstützte z/OS Operations zielt. Dort werden die vier Polaris-Säulen Configuration as Code, AI Assistance, API-first Architecture und CLI Modernization erneut bestätigt. Gleichzeitig stellt IBM eine Verbindung zu Infrastructure Management für IBM Z und LinuxONE sowie zu weiteren Automatisierungsfunktionen her.
Damit zeichnet sich eine Entwicklung ab, bei der Mainframe-Modernisierung zunehmend auch den Betrieb erreicht. In den vergangenen Jahren standen häufig moderne IDEs, Git-basierte Entwicklung, APIs und CI/CD für Anwendungen im Vordergrund. Polaris überträgt einige dieser Prinzipien nun auf Aufgaben, die traditionell im Bereich der Systemprogrammierung liegen.
Das kann langfristig dazu beitragen, Entwicklungs- und Betriebsprozesse auf IBM Z stärker mit den Verfahren der übrigen Unternehmens-IT zu verbinden.
Wo weiterhin Vorsicht angebracht ist
Project Polaris befindet sich im Herbst 2026 weiterhin in einer Technology Preview. IBM beschreibt das Programm als zunächst privat und nur begrenzt verfügbar, wobei später ein breiterer Zugang vorgesehen ist. Funktionen können sich während dieser Phase verändern, erweitert werden oder in einer späteren Produktversion anders aussehen.
Deshalb wäre es derzeit verfrüht, bestehende Betriebsverfahren bereits auf eine zukünftige Polaris-Architektur auszurichten.
Sinnvoll ist dagegen, die zugrunde liegenden Prinzipien zu betrachten und sie mit der eigenen z/OS-Umgebung zu vergleichen. Unternehmen können bereits heute untersuchen, wie Konfigurationen dokumentiert werden, welche Änderungen nachvollziehbar versioniert sind, wo manuelle Prüfungen stattfinden, welche Abhängigkeiten von einzelnen Spezialisten bestehen und wie gut z/OS in übergreifende Automatisierungsprozesse eingebunden ist.
Diese Analyse behält ihren Wert auch dann, wenn einzelne Polaris-Funktionen später anders umgesetzt werden als in der heutigen Technology Preview.
Eine interessante Entwicklung für den z/OS-Betrieb
Project Polaris zeigt, in welche Richtung IBM die Administration von z/OS weiterentwickeln möchte. Die Plattform selbst verliert dadurch weder ihre Besonderheiten noch ihre technische Tiefe. Für die tägliche Arbeit könnten jedoch Zugangswege entstehen, die viele vertraute Verfahren aus moderner Softwareentwicklung und Infrastrukturautomation aufgreifen.
Configuration as Code schafft eine Grundlage für versionierbare und reproduzierbare Konfigurationen. Git verbessert die Nachvollziehbarkeit von Änderungen. Schema-Validierung kann bestimmte Fehler früher erkennen. Eine gemeinsame API-Schicht erleichtert die Entwicklung weiterer Werkzeuge und Integrationen. Die modernisierte CLI schafft einen vertrauteren Zugang für Administratoren mit UNIX- und Linux-Erfahrung. Über MCP erhält schließlich auch der AI Assistant einen Weg, Antworten mit Informationen aus dem tatsächlich vorhandenen System zu verbinden.
Erst das Zusammenspiel dieser Komponenten macht Polaris technisch interessant.
Für Unternehmen mit großen z/OS-Umgebungen lohnt es sich deshalb, die Entwicklung aufmerksam zu verfolgen und gleichzeitig die eigenen Betriebsprozesse zu überprüfen. Die Frage, wie viel Wissen heute in wiederholbaren Verfahren steckt und wie viel weiterhin ausschließlich durch die Erfahrung einzelner Spezialisten verfügbar ist, lässt sich unabhängig von Polaris beantworten.
IBM versucht mit Project Polaris, genau an dieser Stelle neue technische Möglichkeiten zu schaffen. Gelingt es, die angekündigten Konzepte in einer produktionsreifen Form umzusetzen, könnte sich die tägliche Arbeit mit z/OS spürbar verändern, ohne dass dafür die bewährten Eigenschaften der Plattform aufgegeben werden müssen.