Ein Nein zum Wandel bestraft der Markt – aber der Mainframe ist nicht das Problem!
Red Hat
von Armin M. Warda, FSI EMEA Chief Technologist, Red Hat
Für viele altgediente Anwendungen, die auf Mainframes laufen, wird es immer schwieriger, in der digitalen Wirtschaft zu bestehen. Cloud-native FinTechs und Neobanken erobern Marktanteile, angetrieben von den schnelleren Innovationszyklen und niedrigeren Kosten, die die Cloud bietet. Die Hersteller von Mainframes haben schon lange erkannt, was auf sie zukommt, haben ihre Mainframes für Open-Source-Software wie Linux geöffnet und fokussieren sich nun auf Cloud-Plattformen. Aber das ist ein irreführendes Bild.Anwendungsmodernisierung ist nicht unbedingt eine Frage von Mainframes oder Cloud. Viele Banken und Versicherungen schätzen Mainframes nach wie vor wegen ihrer hohen Rechnerleistung sowie Zuverlässigkeit und wollen nicht auf die Maschinen verzichten.”
Vielmehr geht es um die darauf laufenden Legacy-Anwendungen, die durch monolithische Architekturen, proprietäre Standards und Protokolle sowie ältere Programmiersprachen geprägt sind, für die es immer weniger erfahrene Fachkräfte gibt. Wir sprechen hier von Experten, die sich in Legacy-Sprachen wie PL/1 (Programming Language ONE), COBOL, Natural, Ada, Assembler und vielen anderen auskennen.
Die Modernisierung von Applikationen gewinnt vor diesem Hintergrund zunehmend an Relevanz. Allerdings muss das nicht zwangsläufig eine Migration von Mainframes auf andere Systeme bedeuten.”
Wie kann ein Unternehmen der Finanzbranche also entscheiden, welcher Ansatz der beste für die eigene Organisation ist?
Eine gespaltene Haltung ist in Ordnung
Es kann verlockend sein, diese Frage „binär“, also aus zwei völlig unterschiedlichen Sichtweisen, zu analysieren. Auf der einen Seite stehen die Vertreter einer radikalen Neuausrichtung, die nur die Kosten und die Behäbigkeit ihrer Mainframes betonen und sie so schnell wie möglich ausmustern wollen. Auf der anderen Seite stehen die konservativen Bewahrer, die nicht bereit sind, die Erfolgsgeschichte ihrer Mainframes mit niedrigen Latenzzeiten und hoher Sicherheit zu gefährden, insbesondere beim Einsatz für unternehmenskritische Kernanwendungen.
Armin Warda hilft als Chief Technologist Kunden und Partnern aus der Finanzbranche, Open-Source-Technologien effizient, sicher und regelkonform einzusetzen und begleitet sie auf ihrem Weg in die hybride Cloud. Ein Themenschwerpunkt seiner Arbeit sind neue europäische Richtlinien wie der Digital Operational Resilience Act (EU-DORA) und der Artificial Intelligence Act (EU-AIA) sowie die Transformation des Zahlungsverkehrs durch neue Instrumente der Geldpolitik, allen voran den digitalen Euro. Aber auch der Themenbereich Environment, Social & Governance (ESG) und eine vertrauenswürdige KI gehören zu seinen Steckenpferden. Armin Warda verfügt über langjährige Berufserfahrung in der Finanzbranche: Der Diplom-Informatiker hat sich vor seinem Wechsel zu Red Hat (Webseite) über 20 Jahre als Senior IT-Architekt der Postbank Systems mit der Weiterentwicklung der IT-Infrastrukturen von Postbank und Deutscher Bank beschäftigt.Ein richtig oder falsch gibt es allerdings nicht. Wie jedes Unternehmen streben auch Finanzinstitute und Versicherungsunternehmen nach technologischer Effizienz, um innovativ zu sein und auf Geschäftsanforderungen in angemessenem Tempo zu reagieren. Das heißt aber nicht, dass sie ihre Investitionen in die derzeitigen Systeme so einfach abschreiben wollen. Zudem scheut jeder die Risiken, die mit einem zu schnellen Wechsel verbunden sind. Das führt zu Unsicherheiten – und je größer ein Unternehmen ist, desto mehr offene Fragen und Zweifel gibt es.
Auf der anderen Seite sucht man einen einheitlichen Lösungsansatz vergeblich. Was für das eine Unternehmen sinnvoll ist, ist für ein anderes nicht das richtige. Deshalb ist es unabdingbar, die erforderlichen Informationen – verwendete Technologien, benötigtes Datenvolumen, Lebensdauer und Kritikalität der Anwendung, MIPS-Verbrauch und SLA-Anforderungen – zu sammeln und daraus die richtigen Entscheidungen abzuleiten. Große Institute werden zudem ihre eigenen Modernisierungs- und Zeitpläne festlegen wollen, die sich an verändernde oder unvorhersehbare Situationen anpassen lassen. Mit anderen Worten:
Sie wollen eine Technologie, die Unklarheiten ausgleicht, anstatt sie zu bestrafen.”
Fünf Möglichkeiten, eine Anwendung zu modernisieren
Wie sollten Banken und Versicherer nun vorgehen, wenn sie ihre auf einem Mainframe laufenden Anwendungen modernisieren wollen? Im Großen und Ganzen gibt es fünf Möglichkeiten – von der Beibehaltung des Mainframes bis hin zur Migration auf ein hybrides beziehungsweise vollständiges Cloud-Modell.
1. Replacement: Die bisherige Anwendung wird außer Betrieb genommen und durch eine Applikation, die von Grund auf neu implementiert, angepasst und eingeführt werden muss, ersetzt. Obwohl dies auf organisatorischer Ebene eine Umstellung ist, handelt es sich nicht um eine Modernisierung im eigentlichen Sinne. Die Anwendung wird vielmehr „abgeschafft“. Allerdings ist in der Regel eine Phase der Koexistenz erforderlich, während der die Daten in die neue Anwendung migriert und Anpassungen sowie Übernahme abgeschlossen werden.
2. Emulation/Rehosting: Die Anwendung wird auf eine kostengünstigere Deployment-Plattform verschoben, ohne dass es große Auswirkungen hat. In der Regel nutzen Unternehmen Emulation/Rehosting als vorübergehende Maßnahme vor der endgültigen Einstellung eines Systems. Auch hier handelt es sich also nicht um eine echte Modernisierung. Genauso wenig wird das Problem der fehlenden Fachkräfte, die sich beispielsweise mit den alten Programmiersprachen auskennen, adressiert.
3. Translation: Der Anwendungscode wird neu geschrieben – entweder automatisch (schnell, aber mit dem Risiko von Ungenauigkeiten und einer möglicherweise zukünftig nicht so gut wartbaren Codebasis) oder manuell (genauer, aber aufwändiger). Diese Option hilft, alte Programmiersprachen zu entfernen, die mit teuren Compilern und Laufzeitumgebungen einhergehen und für die es zunehmend schwieriger wird, qualifizierte Mitarbeiter zu finden. Stattdessen werden die Anwendungen in moderne Sprachen übersetzt, die gängige Compiler und Laufzeitumgebungen verwenden – idealerweise aus dem Open-Source-Umfeld. Wenn sich Unternehmen größtmögliche Flexibilität für die Zukunft sichern wollen, sollten sie den Code für eine Cloud-native Umgebung umschreiben lassen. Ist dies der Fall, kann die Anwendung überall laufen – in einer Public Cloud, in einer privaten Cloud, auf Servern oder eben auf dem Mainframe.
4. Refactor: Ausgewählte Komponenten der Anwendung werden umstrukturiert, damit Container und Microservices genutzt werden können, während andere Elemente unangetastet bleiben.
5. Rearchitect/Rebuild: Die komplette Anwendung wird von Grund auf neu designt und neuer Programmcode entwickelt.
In der Realität ist bei Banken oder Versicherungskonzernen, die Hunderte von verschiedenen Applikationen betrachten müssen, wahrscheinlich eine Mischung aus den genannten Optionen erforderlich. Hinzu kommt, dass bei jeder Modernisierungsalternative – vor allem aber beim Neuschreiben des Codes oder beim Refactoring – Komponenten derselben Anwendung gleichzeitig in verschiedenen Umgebungen laufen und miteinander interagieren werden. Und da eine Modernisierung bekannterweise Zeit braucht, muss jede dieser Optionen ständig gewartet und verwaltet werden.
Komplexität lässt sich überwinden
Die Konsequenz ist eine nicht zu unterschätzende Komplexität: Läuft eine Anwendung komplett auf dem Mainframe, muss man sich nur um eine einzige Infrastruktur kümmern. Sobald Unternehmen jedoch andere Deployment-Modelle einführen und damit beginnen, einzelne Applikationen zu zerlegen und an verschiedenen Orten auszuführen, droht ein Chaos.
Alle wirtschaftlichen wie auch produktiven Vorteile, die sich die Verantwortlichen langfristig erhofft haben, können zunichte gemacht werden, wenn man diese Komplexität nicht schnell in den Griff bekommt.”
Lange Zeit war es vor allem diese Herausforderung, die große Banken und Institutionen davon abgehalten hat, ihre Anwendungen zu modernisieren. Doch mit Enterprise-Kubernetes-Plattformen und Implementierungspartnern, die deren Fähigkeiten für ihre Kunden aus der Finanz- und Versicherungsbranche nutzen, ändert sich die Situation gerade. Die Partnerschaft aus Technologie und Fachwissen gibt Banken und Instituten die Möglichkeit, ihre Anwendungen zu ihren Bedingungen und in ihrem eigenen Tempo zu modernisieren – und somit Umstellungsrisiken unter Kontrolle zu behalten.
Moderne, Kubernetes-basierte Plattformen bieten DevOps-Frameworks, um eine Anwendung effizient zu modernisieren oder von Grund auf neu zu erstellen. Zudem sind sie umgebungsunabhängig, das heißt, Applikationen und ihre Komponenten können auf mehrere Deployment-Modelle verteilt und leicht zwischen ihnen verschoben werden. Damit wird nicht nur die aktuelle Infrastruktur (einschließlich Mainframes) unterstützt, sondern auch für die Zukunft ist die notwendige Portabilität garantiert.
Sollte ein Modernisierungsprojekt ins Stocken geraten, etwa weil es zu Performance-Problemen durch erhöhte Latenzen kommt, so kann es unterbrochen oder auf den Mainframe zurückgezogen werden, ohne dass die Arbeit umsonst war.”
Ebenso kann eine Anwendung zwischen privaten und öffentlichen Clouds hin- und hergeschoben werden, wodurch das Risiko eines Vendor Lock-in vermieden wird.
Red Hat
Ob nun radikaler Neudenker, konservativer Bewahrer oder irgendetwas dazwischen – Enterprise-Kubernetes-Plattformen, die Anwendungsportabilität und Interoperabilität der eigenen Rechenzentren und Mainframes mit privaten und öffentlichen Clouds gewährleisten, machen es möglich, dass Banken und Finanzinstitute ihre Legacy-Anwendungen heute mit geringeren Risiken als je zuvor modernisieren und zukunftssicher gestalten können.Armin Warda, Red Hat
Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/140923
Schreiben Sie einen Kommentar