Mainframes braucht es auch im Cloudzeitalter. Doch ihre Modernisierung und die Transformation der Applikationen muss einer klaren Strategie folgen. Das Ziel definiert die Architektur und mündet in einen kontinuierlichen Prozess – vorausgesetzt, man hat den richtigen Partner.
Viele Unternehmen haben sich bereits für eine Cloud-First-Strategie entschieden – auch solche, die viele geschäftskritische Prozesse (noch) auf dem IBM-Mainframe betreiben. Von diesen Mainframe-Systemen hängen in der Regel viele andere Systeme im Unternehmen ab. Sie funktionieren seit Jahren und sind sozusagen die «Arbeitstiere», die oft Nacht für Nacht die hohen Mengen an aufkommenden Daten und Transaktionen zuverlässig verarbeiten. Trotz dieser Leistung stehen Mainframe-Systeme und ihre Applikationen vor einem grundlegenden Change: Hohe Kosten mit wenig Transparenz gehen mit monolithischen Architekturen einher; die meisten Lösungen sind noch proprietär und ihre Modernisierung scheint schier aussichtslos. Nicht erstaunlich, dass die Transformation von Mainframe-Applikationen einer Operation am offenen Herzen gleicht.
Transformation von Mainframe in die Cloud ist nicht trivial
Zum Start empfiehlt sich ein Application Landscape Assessment, das die Total Cost of Ownership (TCO) dahingehend bewertet, wie optimal der Mainframe durch die Applikationen genutzt wird, wie dringend die Applikationen der besonderen Mainframe-Features bedürfen und wie weit die Mainframe-Systeme vom heutigen Stand der Technik entfernt sind. Der Standardisierungsgrad der verwendeten Software und Tools ist ebenfalls entscheidend, genauso wie der Reifegrad der gelebten Entwicklungs- und Betriebsprozesse in Bezug auf DevOps. Und letztlich muss es bei der Festlegung einer Mainframe-Modernisierungsstrategie vor allem auch um eine Know-how-Transition gehen, die entweder mit kundeninternen oder den Ressourcen eines Partners gestemmt wird.
Etablierte Modelle und Methoden sind hilfreich
Zur Klassifikation von Transformationsstrategien für Legacy-Systeme hat sich ein Gartner-Modell etabliert, das vor allem die Architekturebene in den Fokus nimmt. Die Digitalisierungsreise beginnt oft mit der Migration in die Cloud. Doch wenn man die Applikationen nicht transformiert, wird die Prozess-Digitalisierung nicht vorankommen. Sollen kurzfristig Kosten reduziert werden, wird mit den «unteren» Architekturebenen begonnen, d.h. ein Rehost oder Replatform erwogen. Um jedoch z.B. eine schnellere Time-to-Market im Entwicklungsprozess, eine bessere Datenintegration oder Plattformunabhängigkeit der Business-Applikationen zu erreichen, müssen die «oberen» Architekturebenen mit einem Refactor oder Rearchitect angegangen werden. Neue digitale Geschäftsmodelle werden erschlossen, wenn die Modernisierungsaktivitäten auch die Geschäftsprozesse und damit die Ebene Rebuild einbeziehen. Bei der Transformation kommt es generell darauf an, ein Schritt-für-Schritt-Vorgehen mit hohem Automatisierungsgrad zu wählen und nicht eine Big-Bang-Lösung anzustreben, damit das Risiko kontrollierbar bleibt.
Wahl des richtigen Partners ist entscheidend
Der Future Mode of Operation liegt auch in der Schaffung von Strukturen und Prozessen, die eine kontinuierliche Transformation ermöglichen. Dazu gehört der Betrieb des FMO im kompletten Stack durch DevOps-Modelle und Strategien für das kontinuierliche Housekeeping. Der Partner für diese Transformation muss die Fähigkeit zur Begleitung über den kompletten Prozess mitbringen: Von der Plattform bis zur Businessapplikation und End-to-End über die Phasen Assessment – Plan – Build – Run sollte er abhängig von der Kundenanforderung Verantwortung übernehmen. Erfahrung, Herstellerneutralität sowie die Kompetenz über den kompletten Technologiestack sind weitere wesentliche Kriterien. Das bedeutet auch, dass er Mainframe as a Service auf Basis verschiedenster Cloudmodelle – hybrid, Public oder Multicloud – anbieten kann. Der Kundennutzen muss im Vordergrund stehen: wenig Risiko, geringere Kosten, Skaleneffekte beim Betrieb in «shared Environments» und letztlich mehr Innovation.
