Das letzte Mainframe geht vom Netz

Der Abschied von den verlässlichen, hochverfügbaren und insbesondere für transaktionsorientierte Systeme perfekt ausgelegten Großrechnern ist kein leichter Schritt. Er wird jedoch nicht nur deshalb nötig, weil ihr Betrieb im Vergleich zu virtualisierten Serverarchitekturen immer teurer wird. Es gibt auch immer weniger IT-Personal, das sich mit der Mainframewelt auskennt - qualifizierte Fachkräfte werden zum Problem. Doch die Hürden sind hoch: Viele der Anwendungen auf Mainframes werden allein deshalb im Betrieb gehalten, um Migrationsprobleme- und Kosten, aber auch Rechtsunsicherheiten zu vermeiden.

Je komplexer und unternehmenskritischer die Systeme auf einem Mainframe sind, desto mehr Geduld und Vorsicht erfordert die Ausmusterung. Meist gehen mehrere Jahre ins Land, bis "der Stecker gezogen" werden kann. Am Anfang eines solchen Projekts kommt es vor allem auf eine Dokumentation aller Anwendungen und Schnittstellen an, denn die Anwendungen müssen auf Serverbasis neu angebunden werden. Insgesamt gilt sowohl für interne IT-Abteilungen als auch für Dienstleister: Der Abschaltungsprozess sollte so gestaltet werden, dass der Anwender so gut wie nichts davon mitbekommt. Zudem sind eine zentrale Steuerung, am besten mit einem zentralen Ansprechpartner beim Kunden, permanente Transparenz und genaue Kenntnis der Prozessreihenfolgen wesentliche Erfolgsfaktoren.

Kostenvorteile sind schwer kalkulierbar

In der Regel sind die Kosten neben dem Wunsch nach Modernisierung der stärkste Treiber für eine Mainframeablösung. Dazu zählen Lizenzkosten und Hardware, Schnittstellen hin zu Speichereinheiten und der Kostenblock des Personals, das die Mainframe-Systeme administriert und Schnittstellen weiterentwickelt. Ob der Wechsel zu neuen Plattformen wirklich wirtschaftlich ist, lässt sich allerdings schwer quantifizieren. Auf dem Weg zur Abschaltung ergeben sich in der Regel vielfältige Entscheidungen, die geplante Kosteneinsparungen sprengen - an anderen Ecken kann es hingegen besser laufen als geplant. Die Weltraumbehörde NASA beispielsweise hat ihren letzten Mainframe IBM z9 in 2012 abgeschaltet. Man hatte das Gerät noch behalten, um Applikationen zu betreiben, die ohnehin auf Sicht "in Pension" gehen sollten. "Es war kosteneffizienter, die bestehende Architektur zu behalten, als auf eine Server-Umgebung zu migrieren", schrieb NASA-CIO Linda Cureton in einem Blog und ließ auch ein bisschen Sentimentalität durchschimmern. Im Vordergrund für eine Abschaltung sollte vor allem die strategische Entscheidung für eine modernere Plattform stehen. Wer nicht mit der Zeit geht, läuft irgendwann in eine Sackgasse: Zeitgemäße Applikationen machen es einfacher, neue IT-Mitarbeiter zu finden und erschließen neue technologische Möglichkeiten.

Die Reste abräumen

Als besonders aufwendig erweisen sich in der Regel die restlichen Applikationen, die auf dem Mainframe zurückbleiben, nachdem die wichtigsten Anwendungen in der neuen Umgebung laufen. Unter den Resten sind teilweise jahrzehntealte Dienste, von denen niemand mehr Kenntnis hat und deren Dokumentation fehlt. Der Aufwand, diese Anwendungen zu analysieren, steht kaum im Verhältnis zur möglichen Risikominimierung. Doch von Big-Bang-Aktionen kann hier nur abgeraten werden. Die Praxis zeigt, dass tatsächlich immer wieder vitale Nervenstränge getroffen werden, wenn auf gut Glück Dienste abgestellt werden. Im TUI-Projekt hat sich eine Struktur bewährt, die das Unternehmen mit seinen Abteilungen gespiegelt hat und an den Anwendungsbereichen wie Agenturwesen oder Flugbereich ausgerichtet war. Schrittweise wurden zunächst nachts im Lauf der Woche einzelne Bereiche abgeschaltet und am Morgen danach für das jeweilige Arbeitspaket geschaut, ob es negative Auswirkungen gab. Dazu gehörten auch kritische Batches, die nachts liefen, und Tausende von Jobs wie Datensicherungen, die im Lauf der Zeit über komplizierte Netze aufgebaut wurden. Dabei zeichneten sich relativ schnell einige Aha-Effekte und Muster ab, auf welche Dinge besonders stark geachtet werden muss. So sollten alle Jobs im Bereich von Datenbanksicherungen mit besonderer Vorsicht behandelt werden. Ein Jobsteuerungssystem wie UC4 hilft bei der Transparenz.

Stellen, an denen es wehtut

Die Online-Anwendungen der TUI waren in CICS (Customer Information Control System) für IBM z/OS implementiert. Bedingt durch die komplexen Strukturen des ehemaligen TUI Reservierungssystems gab es eine Vielzahl von CICS-Systemen mit entsprechend vielfältigen Wechselwirkungen.

Manche Anwendungen bzw. Transaktionen benötigen mehrere CICS-Systeme für Zugriffe auf remote Ressourcen. Hier müssen kritische Funktionen gegebenenfalls wieder aktiviert werden. Generell machen besonders Datenbankthemen Probleme. Da die Datenbanken sich selbst optimieren, fallen Abhängigkeiten oft erst dann auf, wenn versucht wird, einzelne Teile abzuschalten. Diese Selbstverwaltung ist für den Anwender schlicht eine Black Box, es macht deshalb Sinn, einen Bogen darum zu schlagen. Im TUI-Projekt wurde das Datenbankumfeld völlig gekapselt. Diese Umgebung haben wir erst abgeschaltet, als keine Anwendung mehr produktiv auf dem Mainframe lief - als letzte Tat. Erstaunlich wenig Probleme ergaben sich hingegen mit dem gesamten Daten-Output, darunter Vakanzlisten, Stammdaten und Reisebüroabfragen. Anders als erwartet, gab es keinerlei Aufschrei in den Fachbereichen. Rund ein Jahr wurde konkret mit Akribie und Aufmerksamkeit am Abräumen der Reste gearbeitet. Dabei waren die Mainframe-Administratoren und zwei Datenbankadministratoren involviert, ebenso wie Anwendungsentwickler und eine Arbeitssteuerungstruppe.

Was zu bedenken ist

der vorstehende Satz hat m.E. nichts mit Rest des Absatzes zu tun. Mit dem Auszug des Großrechners gehen der Arbeitsinhalt und das liebgewonnene "Baby" von hochspezialisierten Mitarbeitern verloren. Für sie sollten frühzeitig neue Aufgaben identifiziert sowie entsprechende Entwicklungsmaßnahmen und Zielvereinbarungen eingeleitet werden.

Eine nicht unerhebliche Hürde besteht darin, auf der Applikationsseite den Ablauf der Lizenzen und deren Kündigung genau zum richtigen Zeitpunkt zu timen. Viele Lizenzgeber lassen sich nicht auf eine Vergabe für nur drei oder vier Monate ein. Im TUI-Projekt ging es beispielsweise allein um rund 24 größere Lizenzgeber mit gut 53 Verträgen. Wer ein gutes Lizenzmanagementsystem hat, ist hier klar im Vorteil. Doch häufig haben die Unternehmen im besten Fall die moderneren Anwendungen automatisch katalogisiert. Ansonsten gilt es, sich manuell einen Überblick zu verschaffen. Es gehört zu den größten Sisyphus-Aufgaben herauszufinden, welche Verträge und Lizenzen bestehen und was im Laufe der Jahrzehnte eingekauft wurde. Viel Zeit sollte auch dafür eingeplant werden, die jeweiligen Unternehmen anzuschreiben, die in Teilen mittlerweile unter ganz anderen Namen firmieren. Einige Lizenzgeber tun sich zudem schwer mit der Umsetzung von Kündigungen: Obwohl die Kündigungsbestätigung bereits vorliegt, kommen weiterhin Rechnungen ins Haus geflattert.

Wenn der Mainframe auszieht

Wenn die Anwendungsseite endgültig abgewickelt ist, geht es um die harten Fakten: Wie verlässt der Mainframe das Rechenzentrum? Am besten haben es da noch die Leasingnehmer, denn hier ist der Leasingpartner für die Abholung zuständig. Ungefähr so viel wie ein E-Klasse-Mercedes wiegt so ein Gerät, mit einer Sackkarre ist es also nicht getan. Wenn eine Weiterverwendung geplant ist, bedarf es einer feuchtigkeitsabweisenden und elektrostatischen Verpackung in Styroporkügelchen. Zudem muss der Spediteur sich im Rechenzentrum gut bewegen können und über entsprechende Gerätschaften wie Flaschenzüge verfügen. Soll der Mainframe verschrottet werden, gilt es, sich nach einem Schrotthändler umzusehen, der das Gerät kiloweise abnimmt und ordnungsgemäß abtransportiert. Hier gibt es einige schwarze Schafe, auf Seriosität sollte also geachtet werden. (rw)