Mainframe: Der betriebskritische Bremsklotz

Der Mainframe muss weg. So kurz und prägnant lautet die Formel. Warum die baldige Ablösung der IT-Monolithen bald kommen muss, zeigt dieser Beitrag. Am Ende wird zu sehen sein: Der Mainframe kann auch guten Gewissens weg, aller immer noch vorhandener Vorteile zum Trotz.

von Massimo Guarnieri, Europe Lead für Azure Platform Services bei Avanade & Dr. Robert Laube CTIO Avanade Deutschland 

Jene Teams, die den Mainframe mit seinen hohen SLAs perfektionierten, haben auch viele Managementprozesse und -vorgänge als Wissens-Insel gestaltet – darum sind sie heute Innovationshemmnis. Und genau diese erfahrenen Fachkräfte werden immer seltener und teurer. Wir sprechen hier von Experten, die sich in Legacy-Sprachen wie PL1 (Programming Language ONE), COBOL, Natural, ADSA/O, Assembler und viele anderen auskennen und entwickeln können. Das ist herausfordernd, weil die „Baby-Boomer“ jetzt dem Rentenalter entgegensteuern: Studien bestätigen, dass die Verfügbarkeit von Programmierern und Systemingenieuren seit 2018 die Fähigkeit zur Beibehaltung von SLAs und zur Verbesserung von Anwendungen erheblich beeinträchtigt. Diese Erhebungen deuten darauf hin, dass Unternehmen kritische Fachkenntnisse mit einer Rate von 50 Prozent pro Jahr verlieren werden.

Auch gab es schon solche Anzeichen, als entsprechende Programmierer während der „Corona-Krise“ nicht verfügbar waren, während z. B. IT-Abteilungen der US-Bundesstaaten dringend COBOL-Entwickler angefordert hatten – denn die Verwaltungen konnten erforderliche Änderungen an den Applikationen nicht umsetzen, um die von der Regierung geforderten Hilfen für die Bevölkerung und kleinen Unternehmen bereitstellen zu können. Es wird also kompliziert sein, entsprechende Systeme bis 2022 oder länger am Leben zu erhalten. Bei den Kosten lohnt der Schwenk zurück zur Technik, die zwar performant, aber auch teuer ist. Mainframes können Millionen von Transaktionen pro Sekunde ausführen, und sie kosten Millionen von Euro oder Dollar pro Monat im Unterhalt – definitiv viel im Vergleich zu anderen Optionen.

Einst Schubhebel, jetzt Innovationsbremse

Da Mainframes in Banken kritische Plattformen betreiben und deren digitale Revolution mit ihren Daten befähigen (sollen), stellt sich die Frage: Werden Banken sie auf Sicht überhaupt noch betreiben können? Langfristig entscheidend ist auch: Hindern sie diese Plattformen, innovativ zu sein und auf Geschäftsanforderungen in angemessenem Tempo zu reagieren? Immerhin erhalten Cloud-Plattformen wie Azure jedes Jahr über 1.000 neue Funktionen oder Fähigkeiten, also grob etwa 100 pro Monat. Die Beibehaltung eines Ein-Release-Zyklus pro Quartal als Standard, wie in vielen Banken und Versicherungen nach wie vor üblich, wird kaum ausreichen.

FinTechs schaffen 20 oder mehr Releases pro Tag. Festhalten am Bewährten kann Wettbewerbsvorteile kosten – oder sogar das Überleben.”

Fehlende Fachkräfte, hohe Kosten, mangelhafte Zukunftsfähigkeiten rund um agile Entwicklung, fehlende Innovation – das ist das „Warum“ zur Mainframe-Ablösung. Gartner hat sieben Optionen für das „Wie“ identifiziert. Da eine einheitliche Lösung in komplexen Umgebungen Wunschdenken ist, hilft diese Vielfalt sogar. Jede Anwendung oder jede Gruppe von Anwendungen benötigt eine spezifische Herangehensweise.

Faktoren sind insbesondere der Wertbeitrag für das Geschäft, die Lebensdauer, der Änderungsgrad im Entwicklungszyklus, die Stabilität, die Anzahl der Benutzer, spezifische finanziellen Auswirkungen und technische Zwänge.”

Je nach Ausprägung ist eine konservativere „Lift & Shift“-Herangehensweise möglich, bei der COBOL bleibt, oder eine radikalere Neufassung in eine moderne Sprache wie Java oder .Net, eventuell unterstützt durch automatisierte Code-Migration.

Wie anpacken?

Es wäre also vor allem in großen Mainframe-Umgebungen mit mehreren laufenden Anwendungen falsch, nur einen einzigen Weg zur Modernisierung zu nutzen. Entscheidend ist es, die richtigen Informationen zu sammeln und daraus die richtigen Entscheidungen abzuleiten. Darauf gilt es zu achten:

• Technologien, aus denen die Anwendungen bestehen: TP-Monitor, Programmiersprachen, Datenbankschnittstellen, Dateien, JCLs, VSAM…Benötigtes Datenvolumen usw.
• Lebensdauer der Anwendung
• Geschäftswert und wie kritisch ist er für das Unternehmen
• MIPS-Verbrauch
• Leistungen und SLA-Anforderungen (HA/DR)
• Anzahl der Ressourcen für Entwicklung und Aufrechterhaltung des Betriebs
• Code-Analyse

Weiterhin sind relevante Faktoren:

• Vorbereitungen für eine Fusion oder Ausgliederung?
• (Wie stark) Müssen die TCO gesenkt werden?
• Ist ein Wechsel vom OPEX-Modell zum CAPEX-Ansatz erforderlich?
• Bedarf an einem schnelleren Entwicklungsansatz?
• Mangel an Mainframe-Entwicklern oder geringe Betriebszugehörigkeit (auch in Bezug auf die nahe Zukunft)?
• Fähigkeit, in die Modernisierung zu investieren (Budget und Ressourcen)
• Ende der Lebensdauer des Rechenzentrums?
• Fähigkeit, auf Geschäftsanforderungen und hohe Geschwindigkeit zu reagieren?

Das sind die Elemente, die wir immer berücksichtigen, wenn wir einen Kunden konsultieren, der seine Mainframe-Modernisierung angehen muss. Beispielsweise würden wir jemandem, der nicht über COBOL-Entwicklungsressourcen verfügt, nicht zu einem Re-Hosting-Ansatz raten – andererseits kann das eine Option sein, wenn Kostenreduzierung ein wichtiger Faktor ist und COBOL-Ressourcen vorhanden sind.

Keine Angst vor der Cloud!

Als Produktionsplattform kann zum Beispiel Azure SLAs, Verfügbarkeit, Leistung und Sicherheit auf dem gleichen Niveau wie Mainframes liefern – solange alles „auf Cloud-Art“ aufgebaut wird: Die Hochverfügbarkeit von Anwendungen wird nicht von der inhärenten Belastbarkeit der Plattform, sondern vom korrekten Design der Infrastruktur und der Anwendungen definiert. IT-Abteilungen müssen hier also anders denken, nämlich „Designed for Failure“ und von monolithischen Anwendungen zu (Mikro-)Diensten, die in mehreren Instanzen und mehreren Regionen eingesetzt werden.

So lässt sich die Fähigkeiten zur Verwaltung der Workloads sowie die Vermittlung der von Azure bereitgestellten Nachrichten nutzen.”

Umdenken ist auch bei der Sicherheit erforderlich. Die Verteidigung des eigenen Perimeters verliert an Bedeutung. Vielmehr zählt, wie die Daten im Ruhezustand und während der Übertragung geschützt werden. Das umfassende Wissen über die jeweilige Cloud-Plattform ist von grundlegender Bedeutung, um die richtigen Optionen für den Aufbau eines effektiven Designs migrierter Legacy-Anwendungen auf den Weg zu bringen. Wer das Gesagte berücksichtigt, kann nun konkrete Ansätze bei der Mainframe-Ablösung genauer in Betracht ziehen, wobei hier Re-Hosting und Re-Factoring im weiteren Verlauf genauer beleuchtet werden.

Re-Hosting oder Lift & Shift

Wenn Legacy-Anwendungen über Rest-Lebenszeit verfügen, COBOL-Entwickler verfügbar sind, die TCO-Reduzierung essenziell und eine einigermaßen kurzfristige, risikobegrenzte Lösung maßgeblich ist, kann Re-Hosting sinnvoll sein. Große Innovationssprünge dürfen dabei aber nicht erwartet werden, und im Endeffekt erhält ein Unternehmen eine Art „Pseudo-Mainframe-Umgebung“. Dennoch sind die Vorteile einer Umstellung auf Linux oder Windows real und greifbar. Die Erfahrung aus echten Geschäftsfällen (keine PoCs) zeigt: Es wurde mindestens eine 50-prozentige Senkung der Betriebskosten erreicht, in den meisten Fällen sogar 70 bis 80 Prozent. Dabei liegt eine ECHTE Rechnung zugrunde, die nicht Äpfel und Birnen vergleicht und etwa Vorteile der Personalreduzierung einpreist; das gilt umso mehr, als Re-Hosting nur wenig Personalkapazitäten freischaufelt:

Im Grunde werden ja Mainframe-Operationen und -Anwendungen auf Linux oder Windows repliziert. So lassen sich andererseits dieselben COBOL-, JCLs-, Datei- und sogar VSAM-Strukturen verwenden.”

Folglich können etablierte Tools und Produkte gut unterstützen – zumal, wenn erfahrene Partner einbezogen werden. Einige der Tools erreichen eine Kompatibilität von etwa 95% zwischen den Plattformen. Selbst wenn das nicht der Fall ist, werden Teams mit in den Zielsystemen beibehaltenen Konzepten wie CICS-Regionen und JCL-Verhalten vertraut sein. Der exakte Ablauf hängt unter anderem davon ab, ob Applikationen gruppiert werden können. Das geht, sofern sie relativ wenig Datenbestand enthalten und nur lose untereinander verbunden sind; eine exakte Evaluierung ist hierzu erforderlich. Für Re-Hosting spricht auch, dass eigene Entwickler den Code wegen der geringen Änderungstiefe kennen und verstehen werden. Bild (2) zeigt einen beispielhaften Re-Hosting-Ablauf über zwei Phasen:

Wenn auch begrenzter, so gibt es doch auch beim Re-Hosting Möglichkeiten für Innovationen. Bei einem Wechsel zu Azure lässt sich die neue Plattform im Hinblick auf agile Entwicklungsansätze und sogar DevOps voll ausnutzen; wenn etwas in COBOL oder PL/1 kodiert ist, lassen sich in der Regel dennoch moderne Tools hochgradig automatisiert entwickeln, testen und einsetzen. Kundengespräche haben uns immer wieder gezeigt: Einer der Hauptvorteile des Re-Hosting-Ansatzes ist – neben der TCO-Senkung – die Fähigkeit, Produkte und Anwendungen schneller zur Verfügung stellen zu können.

Modernisierung von Applikationen

Die Modernisierung von Applikationen steht am anderen Ende des Spektrums zur Ablösung eines Mainframe. Sie ist geeignet, wenn die betroffenen Anwendungen noch einen signifikanten Wertbeitrag liefern und wenn ein Unternehmen über keine relevanten Mainframe-Kenntnisse mehr verfügt sowie wenn Anwendungen nahe End-of-Life oder wegen ihres Alters nicht mehr performant sind, bzw. mit den Geschäftsanforderungen nicht mehr Schritt halten. Aus Legacy-Code – wahrscheinlich prozedural und undokumentiert erstellt wird jedoch nicht automatisiert „cleaner“ objektorientierter Java- oder .net-Code werden. Dennoch können sehr gute und vor allem perfekt wartbare Ergebnisse entstehen, die dem Mainframe in nichts nachstehen. Voraussetzung ist, die Automatisierungsfähigkeiten und Produktivität von Tools perfekt zu nutzen.

Durch die Konvertierung von Anwendungen in moderne Sprachen lassen sich das Potenzial von Plattformen wie Azure besser zu nutzen und Datensilos durchbrechen. Die Verwendung der Core-Daten wird nicht mehr durch zusätzlichen MIPS-Verbrauch teure Rechnungen zur Folge haben. Und wer einmal „Cloud Native“-Anwendungen erstellt hat, kennt die hohe Geschwindigkeit bei der Entwicklung und kontinuierlichen Provisionierung. Weitere Innovationen können durch die Kombination der Anwendungsmodernisierung mit dem Ansatz des „Digital Decoupling“ erreicht werden, das disruptive Situationen für Benutzer, Entwickler und Systemingenieure vermeiden hilft. Bild (3) illustriert diesen Ansatz.

Der Nachteil der Application Modernization liegt in den Kosten – es kostet erst mal viel Geld, und ist schwer quantifizierbar: Code-Komplexität, Volumen und andere Faktoren spielen eine große Rolle, so dass die Spanne von plus 50 bis 300 Prozent reicht. Vor allem bei der Suche nach dem richtigen Leistungsniveau ist zusätzlicher Aufwand erforderlich. Andererseits erhalten Unternehmen ein deutlich höheres Maß an Innovationsfähigkeit. Langfristig dürfte sich das Konzept also lohnen, insbesondere im Vergleich zum kompletten Rewrite.

Checkliste

Wer nun zustimmt, dass der Mainframe wegmuss und sich für das tendenziell passende Konzept entschieden hat oder entscheiden möchte, sollte weitere Aspekte beachten:

• Der Business Case muss an erster Stelle stehen, dokumentiert und präzise, den Status quo und den künftigen Betrieb betreffend. Etwaige Partner sollten in der Dokumentation ebenfalls bereits vermerkt sein.
• Piloten oder Proof of Concepts – Zeit- und Geldverschwendung beim Blick auf die Komplexität und Einzigartigkeit der Mainframe-Anwendungen. Allein das Auffinden einer passenden, isolierten Anwendung würde wohl schon Wochen dauern. Wer wirklich nachweisen MUSS, dass Transaktionen, Screens und Batches korrekt migriert wurden und korrekte Ergebnisse liefern, sollte sich auf eine hohe Investition einstellen, zumal Erfahrungswerte ja fehlen dürften. Zielführender ist in der Regel ein „Proof of Translation“, mit dem die Qualität der Ergebnisse bewertbar wird. Auch ohne Übernahme und Go-Live lassen sich so relativ günstig viele Erfahrungswerte sammeln.
• Ein mehrstufiger Ansatz kann das Risiko reduzieren, da das Projekt in kleine Stücke unterteilt handhabbarer wird. Die Kosten liegen erfahrungsgemäß jedoch mindestens 50 Prozent höher als bei einem „Big Bang“. Mehr Analysen und mehr Tests tragen ebenso dazu bei wie der Aufbau temporärer Schnittstellen und Dateien, die für die noch auf dem Mainframe verbleibenden Anwendungen nötig sind. Die meisten dieser APIs werden im Verlauf nicht mehr benötigt, wo immer mehr Anwendungen vom Mainframe verlagert werden – eine Unternehmensleitung wird das kaum bezahlen wollen. Ein möglicher Weg zur Mehrstufigkeit ist, wenn eine Reihe von Anwendungen zusammengefasst werden können, um sie mit einem ähnlichen Ansatz und ohne zu viele Schnittstellen auszulagern; dies ist jedoch erfahrungsgemäß nur selten der Fall.
• Technologie zu modernisieren, genügt nicht – die Menschen müssen ebenfalls an Bord sein – denn niemand führt (gern/gut) ein Projekt durch, das ihn nach Abschluss überflüssig macht. Ein erfahrener Partner und ein sauber definiertes Change Management sind hierbei hilfreiche Elemente. Ein guter Migrationspartner hilft bei Übergangs- und Schulungsplänen für das Mainframe-Team. Teams brauchen das Gefühl, wertvoller Bestandteil der neuen Plattform zu sein.
• Testen ist ein Eckpfeiler des Erfolgs. Wichtig ist das richtige Maß, denn es muss nicht alles getestet werden, sondern die richtigen und wichtigen Dinge. Empfehlenswert ist häufig ein risikobasierter Ansatz.
• Cloud: ja oder nein? Die Antwort: Es kommt darauf an. Es gibt gute Gründe, Mainframe-Workloads etwa nach Azure zu verlagern, auch wenn sich nicht alle unmittelbar erschließen:
  •  IT-Sicherheit: Wer bedenkt, dass Microsoft 2019 rund eine Milliarde Dollar in neue Fähigkeiten zur Vorbeugung, Bewertung und Reaktion auf Sicherheitsbedrohungen in der Azure-Plattform investiert hat – welches Unternehmen könnte für sich allein eine solche Summe aufbringen? Sicherheit in der Cloud lässt sich außerdem nicht auf die gleiche Weise implementieren, wie es im eigenen Rechenzentrum passieren würde; es reicht nicht aus, die Funktionen von Firewalls zwischen On-Premise und Azure zu vergleichen. Vielmehr muss die richtige Azure-Blaupause mit End-to-End-Verschlüsselung und Datenschutz definiert werden; verstanden werden, wie Netzwerke, Server und Daten voneinander getrennt werden können; wie Benutzerrechte verwaltet werden können etc. Einen Gedanken wert ist auch das Niveau der Compliance-Zertifizierungen, illustriert am Beispiel Azure (Link).
  • Cloud-Plattformen haben, wenn sie gut konzipiert sind, die Flexibilität und die Möglichkeit, situationsbedingt auf- und abwärts zu skalieren. Es fallen also keine Hardware-Kosten an, um Spitzenbelastungen abzudecken, z. B. Berechnungen zum Monats-, Quartals- oder Jahresende oder Verkaufskampagnen etc. – zusätzlich gibt es die Möglichkeit, Echtzeit-Datenanalysen und immense API-, App-Services- und DevOps-Optionen zu nutzen.
• Wenn bei Cloud ein „Ja“ steht, dürfen die anfallenden Kosten dennoch nicht außer Acht gelassen werden, und zwar bei jedem einzelnen Schritt der Implementierung und der Migration. Kosten-Verantwortlichkeit für das Projekt-Team hat sich vielfach bewährt und ist ratsam.

Fazit

Der Mainframe muss weg, und er kann weg. Es bringt keinen Innovations- oder Umsatzvorteil, zu lange am Bewährten festzuhalten. Fußballtrainer kennen das Problem: Es ist schwierig einen Weltmeister auszusortieren oder das Spielsystem umzustellen. Letztlich führt kein Weg daran vorbei, denn die altgedienten Spieler hören irgendwann mit ihrem Sport auf, und dann muss die neue Mannschaft stehen. Seien wir uns ehrlich: In der Weltmeistermannschaft von 2014 hat kein Gerd Müller gespielt, und das Spielsystem mit einem Vorstopper gab es auch nicht mehr.Massimo Guarnieri & Dr. Robert Laube, Avanade