Mainframe Softwarestandardisierung

Dringender Modernisierungs- und Konsolidierungsbedarf

Eigentlich war er nie so richtig weg, der Mainframe. Indes ist es seit den 1990er Jahren recht still geworden um die verlässlichen Großrechner. Technologiesprünge wie Internet, Smartphone oder Cloud Computing standen im Rampenlicht der öffentlichen Wahrnehmung. Die eher langweiligen Dinosaurier in den Firmenkellern rückten in den Hintergrund. Wir bemerken jedoch, dass sich diese Situation seit einigen Jahren spürbar wandelt. Stetig wächst das Interesse am Mainframe. So berichtet eine repräsentative Studie von Micro Focus aus dem Jahr 2014, dass 58% der Befragten in den kommenden fünf bis zehn Jahren weiterhin auf den Mainframe setzen [MiFo]. Gar 22% sehen einen Zeitraum von zehn bis zwanzig Jahren und immerhin 2% geben an, dass der Mainframe über zwanzig Jahre ein wichtiger Teil des Unternehmens sein werden. An der Studie beteiligten sich 590 CIOs und IT-Leiter aus neun Ländern mit einer Unternehmensgröße ab 500 Mitarbeitern – aus Deutschland allein 100 IT-Verantwortliche.

Eine Ursache für das Comeback liegt sicherlich in den einzigartigen Stärken dieses Computersystems. In Fachkreisen unter dem Begriff RAS abgekürzt, ist der Mainframe ein Inbegriff für Reliability, Availability und Serviceability, zu Deutsch Verlässlichkeit, Verfügbarkeit und Gebrauchstauglichkeit [Loh08]. Wie bei allem in der IT gilt jedoch, dass diese Vorteile nur ausgespielt werden können, solange die unaufhaltsam fortschreitende Technologie auch aktiv gepflegt und weiterentwickelt wird. Weiterentwicklung eines Mainframes? Seit dem Boom von Client-Server in vielen Unternehmen Fehlanzeige. Es wurde nur das nötigste gewartet, repariert und aktualisiert. Ein Investitionsstau entstand. Dabei gilt es vieles zu modernisieren, was in den letzten beiden Jahrzehnten liegengeblieben ist. Waren früher nur Kennzahlen wie Million Instructions per Second (MIPS) für Mainframes bezeichnend, stehen heute ihre Sicherheit, Verlässlichkeit, Input/Output-Schnittstelle, Softwarekompatibilität und der hohe Durchsatz gleichermaßen im Fokus [Wik].

Losgelöst von der technischen Notwendigkeit sind Unternehmen dabei, ihre heterogene Mainframe-Landschaft schrittweise zu konsolidieren und damit Hardware, Software sowie Services von einem Standort aus anzubieten. Allzu lange haben diese Organisationen auf einen “Wildwuchs von Großrechnern” geblickt in denen Rechenkapazitäten, Softwarelizenzen und Personal an unterschiedlichen Orten mehrfach redundant vorgehalten wurde. Auch ein zweiter Evergreen, nämlich Mergers & Acquisitions (M&A), führt zur umfassenden Verschmelzung von Mainframe Hardware, Software, der Betriebsorganisation und den Prozessen. Unterstützter dieser intern und extern induzierten Zentralisierungen sind die ausgereiften und fehlerresistenten Netzwerktechnologien sowie die damit verbundenen sinkenden Kosten für die Übertragung von Daten.

‘Integrationssynergien bei Großrechnern’ lautet also das Gebot der Stunde. Doch wie sollte bei der Modernisierung und Konsolidierung von historisch gewachsenen Mainframe am besten vorgegangen werden? Was sollten die IT Abteilungen zuerst und aus welchen Gründen in Angriff nehmen und was kann warten? Basierend auf unseren Projekterfahrungen berichten wir, wie ein Hauptkostentreiber, nämlich die Software eines Mainframes, standardisiert werden sollte.

Kostentreiber Mainframe-Software

War es bis in die 1980er hinein die Hardware, trägt heute die Software zu einem signifikanten Teil der Gesamtkosten eines Mainframes bei. Beispielsweise spricht Gartner von 44% Kostenanteil von Software (vgl. [Gar12]), ein Wert der sich mit denen in unseren Projekten ermittelten Zahlen recht gut deckt. Bei der Konsolidierung von heterogenen Mainframes existieren für eine identische Aufgabe oft mind. zwei verschiedene Middleware Softwareprodukte. Um die wiederkehrenden Kosten für Lizenzen, Betrieb, sowie Wartung und Pflege zu reduzieren muss zunächst ein Standard geschaffen und anschließend nicht-standardkonforme Software vereinheitlicht werden. Nun ist Standardisieren nicht gleich Standardisieren. Die Tücke steckt, wie so oft in der IT, im Detail.

Beim Entschluss einer Standardisierung muss in Ersetzung, Aktualisierung und Stilllegung differenziert werden. Im ersten Fall existiert für das vorhandene Produkt eine vergleichbare Lösung eines anderen Herstellers, eine Softwaremigration inkl. Ausphasung der Altsoftware wird erforderlich. Bei der Aktualisierung, bleiben Hersteller und Produkt identisch. Änderung erfährt die Softwareversion, für die in den meisten Fällen eine Erhöhung (upgrade) in einigen Fällen aber auch eine Zurückstufung (downgrade) erfolgt. Schließlich beinhaltet eine Stilllegung die endgültige Abschaltung der Software, da diese weder fachlich noch technisch mehr benötigt wird. Alle drei Typen ereignen sich zeitlich vor oder nach der Mainframe-Konsolidierung, d.h. vor der Zentralisierung der Großrechner und ihre Betriebsservices. Fällt die Entscheidung auf nach Konsolidierung, dann muss die Software zunächst auf die neue Rechnerumgebung übernommen werden.

Aus unserer Erfahrung mit Mainframe Softwarestandardisierungsprojekten wissen wir, dass sich insb. die Ersetzungen von Software herausfordernd gestalten kann. Größter Aufwandstreiber ist meist das abgebende Produkt, da dieses nur selten über Exportfunktionen verfügt. Auch sind abgebende Hersteller oft nur nach Zahlung hoher Summen dazu bereit, bei der Ablösung ihrer Software zu unterstützen. Im folgenden werden wir daher auf diese Form detaillierter eingehen. Weit weniger komplex verlaufen die Aktualisierungen der Software, speziell falls es sich um Produkte mit einem geringen Datenbestand und -durchsatz handelt. Am leichtesten von der Hand gehen die Stilllegungen, sofern regelt wurde, wie nach der Ablösung mit dem verbleibenden Nutzdaten umzugehen ist.

Mainframe Software schrittweise standardisieren

Neben den aus Softwaremigrationen bekannten Aufgaben (vgl. [Sne10]) stellen sich bei der Standardisierung von Mainframe Middleware Softwareprodukten drei zusätzliche Herausforderungen:

• Die zugrundeliegende (leider oft monolithische) Software ist in vielen Fällen technologisch veraltetet, teilweise existieren die verantwortlichen Hersteller nicht mehr.
• Verfügbares Wissen zu den Softwareprodukten ist nicht oder nur lückenhaft dokumentiert bzw. liegt nur implizit bei dem verantwortlichen Betriebs- und Wartungspersonal vor.
• Experten die sich mit der Ist-Software, der Standardsoftware oder der Migration auskennen stehen kurz vor ihrer Rente (vgl. Kasten 3), verlangen einen hohen Tagessatz, oder beides.

Bei einer Mainframe Konsolidierung hat man es zudem mit einer zwei- bzw. gar dreistelligen Anzahl von zu standardisierenden Softwareprodukten zu tun. Es ist daher erst die Entscheidung zu fällen, welche Vorhaben sofort oder zu einem späteren Zeitpunkt angestoßen werden. Die Zauberformel lautet Priorisierung. In unserem Modell drückt sich dies in zwei leitenden Handlungssträngen aus welche wechselseitig zum Zuge kommen:

• die Untersuchung und Bewertung der kaufmännischen rechtlichen Aspekte durch ein zentral agierendes Mainframe Konsolidierungsgremium
• die Analyse und Evaluation fachlicher und technischer Aspekte sowie die Umsetzung der Standardisierung durch ein dezentrales Projekt

Nachfolgen gehen wir knapp auf die einzelnen Phase und die Besonderheiten beim Mainframe ein.

Grundlage für die initiale Priorisierung ist die Erstellung einer Softwareproduktliste. Die Liste umfasst alle Software welche zu einem definierten Zeitpunkt im Kontext der Konsolidierung der Mainframe Landschaft stehen. Diese Informationen steuert das Lizenzmanagement des Unternehmens in Zusammenarbeit mit der Betriebsmannschaft bei.

Alle Softwareprodukte (Hersteller und Name) auf allen Systemen und Logical Partitions (LPARs) mit allen Versionierungen sind aufzulisten. Ergänzt werden wichtige Kriterien und Fragestellungen:

• “Welches Kostenmodell steckt hinter der Software: eine einmalig gekaufte Software oder ein Lizenzmodell mit vereinbarten Zahlungszyklen unbefristet oder jährliche Verhandlungen mit dem Lizenzgeber?”
• “Welche Laufzeiten sind mit dem Lizenzmodell verknüpft – zu welchem Zeitpunkt besteht Handlungsbedarf?”
• “Wie hoch ist die Anzahl der installierten Instanzen?“
• “In welche Businesskritikalität bzw. Risikostufe ist das Softwareprodukt einzuordnen?”

Die Zahlen und Fakten werden Teil der Business Case Betrachtung. Das Ergebnis des Business Case liefert die Priorisierung, ein Filter dessen Ergebnis die Grundlage für die nächste Phase ist.

Bei großen Mainframe Konsolidierungsprojekten ist u.a. Geschwindigkeit der Schlüssel zum Erfolg. Wir empfehlen der mehrwöchigen Detailbetrachtung der Softwareprodukte eine Voranalyse vorzuschalten. Pro Software dauert dieser “Quick-Check” nicht mehr als fünf Arbeitstage, liefert bereits nach kurzer Zeit eine fachlich und technisch fundierte Übersicht, ob eine Standardisierung vor der Konsolidierung der Mainframes überhaupt realistisch ist. Mittels geschlossenen Fragen an die Wissensträger der Ist- und Standardsoftware werden folgende Aspekte geklärt:

• “Welchem Umfang und Charakter besitzt der Nutzerkreis der Software?”
• “Wie komplex sind Softwarearchitektur, Datenhaltung, Geschäftslogik sowie Schnittstellen?”
• “Wie einfach lassen sich Datenbasis und Geschäftslogik der Ziel-Software adaptieren?”
• “Welcher fachliche und technische Ähnlichkeitsgrad besteht zwischen Ist- und Ziel-Software?”
• “Wie viele Personen benötigen wie lange für eine Standardisierung?”

In der Voranalyse geht es nicht darum das Standardisierungsprojekt vollumfänglich exakt und sicher zu bewerten. Vielmehr ist es das Ziel, in wenigen Tagen eine auf wenigen aber aussagekräftigen Fakten beruhendes Gefühl zu erhalten, ob es sich bzgl. Aufwand um ein kleines (“S”), Mittleres (“M) oder großes (“L”) Vorhaben handelt.

In einer vertiefenden Priorisierung nutzt das Konsolidierungsgremium die Ergebnisse der Voranalyse, um die Softwarestandardisierungsprojekte neu zu bewerten. Zum Einen hinsichtlich der Business Cases, immerhin liegen nun genauere Informationen zu den Migrationsaufwändungen vor. Zum Anderen bzgl. der Zeitleiste, sorgte der Quick-Check ebenso für mehr Transparenz über den notwendigen zeitlichen Rahmen. Alle Standardisierungsvorhaben, die weiter verfolgt werden sollen, hält das Gremium auf einer Analysenliste fest und übergibt diese an das Standardisierungsprojekt.

Für jede Kombination der Ist-Ziel Softwareprodukte stößt das Standardisierungsprojekt eine mehrwöchige Analyse an. In dieser untersucht ein technisch und fachlich versiertes Migrationsteam die zu standardisierende Software inkl. dem dafür erforderlichen Migrationsprojekt. Resultat der Analyse ist ein Bericht, der neben einer technischen Detailbetrachtung auch Angaben zur Projektorganisation (Dauer, Kosten, Risiken, Abhängigkeiten, Ressourcen, etc.) enthält.

Regelmäßig war es in unseren Projekten unausweichlich, externe Mainframespezialisten mit dediziertem Know-How mit ins Boot zu holen. Bis das unterstützende Personal endlich beauftragt, das Zusammenarbeitsmodell geklärt und das Analysenteam endlich produktiv werden konnte, vergingen mehrere Wochen. Bemerkenswert dabei der Umstand, dass sich eine Vielzahl kleiner Migrationsanbieter erfolgreich darauf spezialisiert hat, veraltete und teure Mainframe Middleware Software auf günstigere Standardlösungen zu überführen.

 Auf Basis des Analyseberichts nimmt das Mainframe Konsolidierungsgremium dann seine finale Priorisierung vor: das Votum für oder gegen eine Standardisierung einer Software. Diesem letzten Filter liegen für die verbleibende kleine Anzahl von Softwareprodukten eine große Menge an Analysedaten vor. Erneut wird aus kaufmännischer und rechtlicher Perspektive geurteilt welches Standardisierungsprojekt es auf die finale Umsetzungsliste schafft und somit vor der Mainframe Konsolidierung realisiert wird.

 “Business as usual” – so kann die eigentliche Umsetzung untertitelt werden. In Abhängigkeit um welchen Standardisierungstypus es sich handelt, müssen unterschiedliche Schritte unternommen werden. An dieser Stelle wollen wir nur den Fall Ersetzung diskutieren. Für diese enthält die Umsetzungsphase u.a. die Ausarbeitung eines Migrationskonzeptes, ggf. die Rehstrukturierung des Ist-Softwarecodes, die Anpassung der Soll-Software und die Schaffung von Fallback-Möglichkeiten.

Die Ersetzung selbst vollzieht sich dann in der Regel als Soft-Migration. D.h. Vorgänger- und Nachfolger-Softwareprodukt existieren parallel, eine Übertragung von vergangener in zukünftige Welt findet in Inkrementen (z.B. User-Gruppen, Module) abgesichert durch zahlreiche Testläufe statt. Ein erfolgreicher Abschluss inkl. der Sicherstellung der Benutzerakzeptanz, Ausphasung der Ist-Software und Übertragung der Lessons Learned an andere Standardisierungsprojekte schließen das Projekt ab.

Je nachdem, um welches zu substituierende Softwareprodukt es sich handelt, ist das Standardisierungsprojekt mehr oder minder riskant bzw. umfangreich. Unseren Erfahrungen nach sind besonders Scheduling- und Printing-Softwarekomponenten mit hohem Risiko und Aufwand einzustufen. Einfacher geht die Angleichung von Datenbankwerkzeuge von der Hand, im Mittelfeld liegen Dateitransfer-Tools. Notwendige (aber nicht hinreichende) Voraussetzung für den Erfolg ist ein stringentes Projektmanagement, dass der inhaltlichen Dimension einen organisatorischen Rahmen gibt.

Fazit

Der Mainframe ist gekommen um zu bleiben – diese kurze aber prägnante Einschätzung teilen immer mehr IT Abteilung mittelständiger und großer Unternehmen. Für sie haben Großrechner einen festen Platz in der IT Landschaft eingenommen. Weiterhin gilt aber, dass vielleicht gerade aufgrund ihrer hohen Verlässlichkeit, Mainframes keine günstige IT Lösung sind. Zwar fielen die Preise für ihre Hardware in den letzten Jahrzehnten spürbar, jedoch verdoppelten sich gleichzeitig auch die Ausgaben für Personal und Software [Sey13].

Unternehmen sollten bei strategischen Konsolidierungsvorhaben ihrer Mainframes die Standardisierung der Software unbedingt auf dem Plan haben. Aktuell nutzen einige Softwarehersteller die Alleinstellung und das Spezialwissen ihrer “Cash-Cow” Werkzeuge exzessiv aus, verlangen unangemessene hohe Gebühren für Lizenzen und Wartung. Nicht nur aus finanziellen Gründen lohnt es sich Mainframe Softwareprodukte zu standardisieren. Auch technologisch und organisatorisch profitiert das Unternehmen mittel- bis langfristig von einem harmonisierten Softwareportfolio der Großrechner.

Anmerkung: Dieser Artikel wurde von Dr. Christopher Schulz (mosaiic GmbH) und Torsten Alberti (NOVEDAS Consulting GmbH) erstellt und in der Ausgabe 02/2016 im OBJEKTSpektrum veröffentlicht. Der Artikel wurde für die Veröffentlichung angepasst und gekürzt.

Literatur & Links

[Loh08] S. Lohr: Why Old Technologies Are Still Kicking, New York Times, 23.03.2008
[Gar12] Gartner: IT Key Metrics Data 2013, Dezember 2012
[Gol13] Goldberg, G.: The Mainframe Magna Carta – The promise and reality of the IBM Mainframe Charter and Statements of Integrity, IBM Destination z, November 2014
[MiFo]  Micro Focus 03/2014: Unternehmen setzen weiter auf Mainframes, https://www.microfocus.de/ueber-uns/pressemeldungen/2014/studie-von-micro-focus-zeigt-unternehmen-setzen-weiter-auf-mainframes.aspx (letzter Abruf: 30.09.2015)
[Sey13] Symonds, M.: Mainframes in perspective – a classic goes strong. Utrecht, The Netherlands: Atos SE, 2013
[Sne10] Harry M. Sneed, Ellen Wolf, Heidi Heilmann: Software-Migration in der Praxis: Übertragung alter Softwaresysteme in eine moderne Umgebung, dpunkt.verlag, 2010, 1 Auflage
[Sof12] Software Engineering Radio: Episode 184 – The Mainframe with Jeff Frey, http://www.se-radio.net/2012/03/episode-184-the-mainframe-with-jeff-frey (letzter Abruf: 30.09.2015)
[Ste08] D. Stephens: What On Earth is A Mainframe? (1st ed.). Lulu.com, 2008
[Wik] Wikipedia: Mainframe Computer, https://en.wikipedia.org/wiki/Mainframe_computer (letzter Abruf: 30.09.2015)