In puncto Zuverlässigkeit, Ausfallsicherheit und Performance war der Mainframe bislang unerreicht. Doch an der Mainframe-zentrierten Infrastruktur nagt der Zahn der Zeit: der digitale Wandel der Unternehmen und der zunehmende Fachkräftemangel bereiten den IT-Verantwortlichen nicht nur erhebliche Machbarkeitsprobleme, sondern lassen auch die Betriebskosten für den Mainframe explodieren. Der Software-Defined-Mainframe verspricht nun Abhilfe gleich in mehrfacher Hinsicht.
Einer weltweiten Forrester Research-Umfrage [1] zufolge haben 90% der befragten IT-, I&O- und Entwicklungs-Experten Probleme mit der Mainframe-Anwendungsentwicklung. 48% gaben zudem an, Anwendungen vom Mainframe zu entkoppeln, um schneller entwickeln zu können. Auch aufwändige Workarounds zur Umgehung des Mainframes gehören für 41% der Befragten zum Alltag.
Die Umfrage macht deutlich, was viele IT-Verantwortliche schon lange befürchten. Erstens: es gibt offensichtlich nicht mehr viele Spezialisten, die sich mit der 3270-Interface-Oberfläche älterer Mainframes oder den vielfach noch in Cobol, PL/1 oder Assembler programmierten Alt-Anwendungen auskennen. Zweitens: der Mainframe behindert Innovation.
So steigen einerseits die Betriebskosten für Mainframes immer weiter an. Allein die 350 IBM-Dienstleistungspartner hierzulande setzen pro Jahr nahezu 2 Milliarden Euro um [2]. Der Druck der Fachbereiche auf die IT, Anwendungen für die Cloud, Mobile oder das Virtual-Data-Center zu modernisieren, hat zu einer ‚florierenden‘ Schatten-IT geführt, die weitere Kosten verursacht und die ohnehin knappe Personaldecke vieler IT-Bereiche zusätzlich belastet.
Horror-Projekt: Mainframe-Legacy-Anwendungen modernisieren
Warum wechseln die betroffenen Unternehmen nicht auf ein anderes System? Die besagte Studie belegt die schmerzvoller Erfahrung vieler IT-Verantwortlicher: die Methoden, mit denen Anwendungsentwickler den Mainframe zu umgehen versuchen, oder ein Umzug auf ein anderes System sind nicht gerade ein ‚Zuckerschlecken‘. Die Abkoppelung von Legacy-Anwendungen vom Mainframe bedeutete bislang entweder ein komplettes Re-Engineering der Applikation oder eine Neu-Programmierung des Source-Codes. Angesichts historisch gewachsener Programm-Codes mit einer Zeilenanzahl im hohen zwei- oder gar dreistelligen Millionenbereich auf dem Mainframe werden beide Rehosting-Herangehensweisen jedoch zur Sisyphos-Aufgabe. Extremer Zeit- und Personalaufwand, ein hoher Bedarf an Mainframe-Spezialisten (die aber buchstäblich aussterben), ein ungewisser ROI sowie ein hohes Risiko zu scheitern, lassen IT-Manager vor der notwendigen Loslösung der Legacy vom Mainframe-Großrechner zurückschrecken.
Das eigenentwickelte Portfolio-Management-System (PMS) von GE Capital, der General Electric Finanzdienstleistungssparte, ist so eine exemplarische Alt-Lösung. Die 1987 für einen kleinen Kundenkreis entwickelte Terminverwaltungs-Anwendung hatte sich über fast drei Jahrzehnte hinweg zur zentralen „Lebensader“ im Leasing-Geschäft des Konzerns entwickelt – mit über 5 Millionen Terminen und täglich 3,5 Millionen Transaktionen.
Hohe Wartungskosten, geringe Agilität und das steigende Risiko eines Systemausfalls mit gravierenden finanziellen Folgen erforderten dringend die Migration der 71 Millionen Zeilen Programmcode mitsamt seiner Geschäftslogik und des Datenbank-Managementsystems. Mit der Implementierung der Lösung ‚OpenFrame‘ des Anbieters TmaxSoft setzte GE Capital dazu erstmals auf eine neue Rehosting-Methode – Software- Defined-Mainframe (SDM).
Neuer Ansatz: Ein „softer“ Mainframe
Entgegen Re-Engineering oder einer Neu-Entwicklung von Programmcode migriert dieser vergleichsweise neue Rehosting-Ansatz Legacy-Anwendungen 1:1 von einer Mainframe-Hardware in die offene x86-Systemumgebung eines virtuellen Mainframes. Dabei wird der gesamte Source-Code der Alt-Applikationen per File-Transfer über einen Compiler weitgehend automatisch in ASCII übersetzt. Dies beschleunigt nicht nur den Migrationsprozess, sondern verringert auch das Fehlerrisiko erheblich.
Auf dem SDM laufen die Anwendungen weiter wie gewohnt. Dateien, Datenbanken, Transaktions-Monitoring und Job-Entry-Systeme können im Look, Touch & Feel eines Mainframe dargestellt werden, sodass die Mainframe-Spezialisten weiter auf ihrer gewohnten Oberfläche (3270-Interface) arbeiten können. Fortschrittliche Systeme bieten jedoch auch ein zusätzliches GUI für jüngere Systementwickler, die mit der Mainframe-Welt nicht mehr viel am Hut haben. Damit verbindet das System zwei Entwickler-Generationen und löst gleichzeitig das Problem der Fachkräfteknappheit auf der Mainframe-Seite.
Momentan ist der Kreis von SDM-Lösungsanbietern noch relativ überschaubar. Bei der Wahl einer Lösung sollten Unternehmen aber auf einige wesentliche Kriterien achten: Neueste Lösungen bieten Compiler-Werkzeuge, die den Quellcode bi-direktional übersetzen. So könnte Programmcode beispielsweise über das GUI in JAVA bearbeitet und optional wieder auf die Mainframe-Hardware zurückgespielt werden. Auch eine Schritt-für-Schritt-Migration oder die Migration von Teilbereichen einer Mainframe- Anwendung wird dadurch ermöglicht.
Im Hinblick auf Digitalisierungsprojekte sollte der SDM Cloud-fähig sein und mit gängigen Anbieterlösungen (z.B. AWS) in diesem Bereich zusammenarbeiten. Die Unterstützung von Generation-Data-Groups (GDG) ist ebenfalls von großer Bedeutung, damit bei der Migration Daten nicht fälschlicherweise als Dubletten identifiziert werden. Auch das Vorhalten von Container-Fähigkeit, um Berechtigungen granular vergeben zu können, ist ein Kriterium zur qualitativen Differenzierung der vorhandenen SDM-Lösungen im Markt.
Moderne Umgebung – bewährte Mainframe-Eigenschaften
SDM-Rehosting bietet zahlreiche Vorteile: es öffnet die klassische Mainframe-Welt für Digitalisierungs- bzw. Virtualisierungsprojekte mit einer wesentlich größeren Auswahl an Software – auch aus dem Bereich Open-Source. Im Hinblick auf digitale Entwicklungen in Mobile- oder Cloud-Systemen beschleunigt die offene SDM Systemumgebung die Einführung von Innovationen bzw. verbessert die Reaktionszeiten auf marktspezifische Veränderungen erheblich.
Zusätzlich werden allein durch die Abtrennung einzelner Anwendungen oder Datenbanken vom Mainframe bereits massive Betriebskosten-Einsparungen bei der Mainframe-Hardware möglich.
Der überzeugendste Vorteil eines SDM ist jedoch, dass er seinem Hardware-Pendant in puncto Zuverlässigkeit und Sicherheit in nichts nachsteht. Zum Erstaunen vieler eingefleischter Mainframe-Verfechter ist die Performance bei leistungsstarken SDMs häufig sogar noch höher als beim klassischen Mainframe. Darüber hinaus erhöht sich die Skalierbarkeit: beispielsweise können neue Nodes sehr schnell und einfach geklont und ergänzt werden.
Übrigens: GE Capital schaffte das Re-Hosting ihres PMS innerhalb von 12 Monaten mit einem überschaubaren Eigenaufwand. Mit dem Umzug auf den SDM konnte der Umfang des Programm-Codes von 71 auf 16 Millionen Zeilen deutlich verschlankt werden. Das PMS ist dadurch wesentlich agiler, sicherer und performanter. Zudem konnte das Unternehmen seine Mainframe-Maintenance-Kosten nachhaltig um 66% reduzieren.
Nachdem die Terminverwaltungslösung jahrzehntelang als praktisch unantastbar galt, soll nun bereits die nächste Programm-Generation auf der Grundlage einer offenen, Service orientierten Architektur (SOA) entwickelt werden.
Vier Schritte der Anwendungsmigration auf einen SDM
Phase 1: Ein Diagnose-Tool analysiert den gesamten Anwendungs-Quellcode.
Dabei wird auch „toter“, inaktiver oder „missing“ Code identifiziert. Bei totem Code können die Verantwortlichen selbst entscheiden, ob er gelöscht werden kann, was ggfs. zu einer deutlichen Verringerung des Quellcode-Footprint führt (s. Anwenderbeispiel GE Capital: Reduzierung von 71 auf 16 Millionen Zeilen)
Phase 2: Migration auf einen Standard-Server,
Im Idealfall übersetzen SDM Compiler-Tools automatisiert den Quellcode. Das ist notwendig, denn der EBCDIC (Extended Binary Coded Decimal Interchange Code) einer Mainframe Quelle verwendet einen anderen Hexadezimalcode als ASCII (American Standard Code for Information Interchange).
Phase 3: Funktionstests für notwendige Anpassungen und Systemjustierungen.
Aufgrund der vollständigen Migration von Programmcode und Geschäftslogik der Anwendung ist die Testphase meist erheblich kürzer ist als mit bisherigen Rehosting-Methoden.
Phase 4: Übernahme des SDM in den Effektivbetrieb.
Quellen:
[1] http://www.silicon.de/41637946/mainframe-als-innovationsverhinderer/
[2] https://www.computerwoche.de/a/ibm-stellt-neue-mainframe-generation-z13-vor,3092009
#Netzpalaver
