Auf Mainframe gestützte digitale Transformation für Finanzdienstleistungen setzen

Dies ist der erste Teil einer fünfteiligen Blog-Reihe zum Thema Mainframe-Modernisierung.

Wir haben bereits dargelegt, dass die Mainframe-Modernisierung nicht nur für die Finanzbranche gedacht ist. Warum also nicht auch das Thema angehen? Die weltweit größten Herausforderungen der Modernisierung konzentrieren sich in der Bankenbranche.

Vor dem Internet und Cloud Computing und vor Smartphones und mobile Apps haben Banken Zahlungen über riesige elektronische Zahlungsgateways abgewickelt und Mainframes als Aufzeichnungssysteme betrieben.

Finanzdienstleistungsunternehmen gelten als Institutionen, weil sie die Kernaspekte unseres globalen Wirtschaftssystems verwalten. Und das schlagende Herz von Finanzinstituten ist der IBM Mainframe.

Banken haben am meisten zu gewinnen (und am meisten zu verlieren, wenn sie scheitern), wenn es darum geht, ihre Mainframe-Anwendungen und Datenbestände auf den modernen Standard von Cloud-ähnlicher Flexibilität, Agilität und Innovation zu bringen, um den Kundenanforderungen gerecht zu werden.

In jüngster Zeit haben wir globale wirtschaftliche Unsicherheiten erlebt, von der „Too Big To Fail“ -Krise 2008 bis hin zu unseren aktuellen hohen Zinssätzen nach der Pandemie, die zu einem Überrisiko und zur Insolvenz bestimmter großer Einlegerbanken geführt haben.

Auch wenn Bankenpleiten oft auf schlechte Managemententscheidungen und -strategien zurückzuführen sind, gibt es gute Gründe, verzögerten Modernisierungsinitiativen und -strategien eine gewisse Mitschuld zuzuschreiben. Hätten die Führungskräfte nicht bessere Analysen durchführen können, um Risiken in den Daten zu erkennen? Warum ist es ihnen nicht gelungen, eine neue mobile App zu starten? Wurden die Systeme gehackt und die Kunden ausgesperrt?

Allen ist bewusst, dass die Verzögerung der Modernisierung von Mainframe-Anwendungen Opportunitätskosten mit sich bringt, aber es herrscht die Überzeugung, dass es riskant sei, Systeme zu ändern, die derzeit den Betrieb unterstützen.

Gemeinschafts- und regionalen Banken fehlen möglicherweise die technischen Ressourcen, während größere Institutionen eine überwältigende Menge an technischen Schulden, starke Probleme mit der Datenbewegung oder Schwierigkeiten mit dem Business Case haben.

Große wie kleine Banken sind wahrscheinlich alle schon einmal bei einer oder mehreren Modernisierungs- oder Migrationsinitiativen gescheitert. Als die Bemühungen eingestellt wurden, hatten die IT-Leiter dieser Unternehmen das Gefühl, dass sie mehr abgebissen haben, als sie kauen konnten.

Die Transformation der Modernisierung sollte weder ein umfassendes Umschreiben des Mainframe-Codes noch eine mühsame und teure Lift-and-Shift -Übung erfordern. Stattdessen sollten Teams das modernisieren, was für die wichtigsten Prioritäten des Unternehmens sinnvoll ist.

Hier sind einige großartige Anwendungsfällen von Banken, die über die bloße Wiederaufnahme von Modernisierungsinitiativen hinausgingen, um den Wert ihrer Mainframe im Kontext hochgradig verteilter Softwarearchitekturen und der heutigen hohen Customer Experience deutlich zu steigern.

Viele Banken scheuen sich davor, technische Schulden in ihrem bestehenden Mainframe-Code anzugehen, der vor dem Aufkommen verteilter Systeme möglicherweise in COBOL oder anderen Sprachen geschrieben wurde. Oftmals sind die Ingenieure, die das ursprüngliche System entworfen haben, nicht mehr im Unternehmen, und Betriebsunterbrechungen sind keine gute Option. Daher verzögern IT-Entscheider die Transformation, indem sie an der mittleren Ebene herumexperimentieren.

Atruvia AG ist einer der weltweit führenden Anbieter von Bankdienstleistungen. Mehr als 800 Banken verlassen sich auf ihre innovativen Dienste für fast 100 Milliarden jährliche Transaktionen, unterstützt von acht IBM z15-Systemen, die in vier Rechenzentren laufen.

Statt einer kompletten Neuinstallation entschieden sie sich für eine Refaktorisierung vor Ort und schrieben RESTful-Services in Java parallel zu dem bereits auf den Mainframes laufenden COBOL-Code. Durch den schrittweisen Ersatz von 85 % ihrer Kernbanktransaktionen durch modernes Java konnten sie neue Funktionen für Bankkunden entwickeln und gleichzeitig die Leistung der Workload auf dem Mainframe um das Dreifache verbessern.

Die meisten Banken haben einen Datenschutzplan, der eine Form von Redundanz für die Notfallwiederherstellung (DR) beinhaltet, wie etwa eine Primärkopie des Produktions-Mainframe im Rechenzentrum und vielleicht eine externe sekundäre Backup- oder virtuelle Bandlösung, die alle paar Monate einen neuen Batch-Upload erhält.

Da die Datenvolumina unaufhaltsam zunehmen und immer mehr Transaktionen und Anwendungen umfassen, wird die Erstellung von Kopien durch Altlast-Backup-Technologien immer kostspieliger und zeitaufwändiger, und auch die Wiederherstellung ist langsam, was zu einer Ausfallzeit führen kann. Es besteht ein kritisch, entscheidend Bedarf an Backup und Wiederherstellung, um die Computerumgebung der modernen Bank ausfallsicher zu machen, einschließlich Ransomware.

ANZ, eine der fünf führenden Banken in Australien, wollte ihre Kapazität für zeitnahe Mainframe-Backups und schnellere DR-Leistung erhöhen, um eine hohe Verfügbarkeit für ihre mehr als 8,5 Millionen Kunden zu gewährleisten.

Sie bauten eine standortübergreifende Resilienz-Kapazität auf, indem sie gespiegelte IBM zSystems-Server mit ihrer HyperSwap-Funktion einsetzten, um Multi-Target-Speicher-Swaps ohne Ausfallzeiten zu ermöglichen, da jeder der identischen Server die Produktions-Workload übernehmen kann, wenn sich einer in einem Backup- oder Wiederherstellungsprozess befindet.

Die IT-Führung von ANZ kann sich dank der besseren Systemverfügbarkeit beruhigt zurücklehnen. Darüber hinaus verfügt sie jetzt über eine moderne Notfallwiederherstellung-Lösung, die zertifiziert werden kann, um die Geschäftskontinuität für ihre Kunden sicherzustellen.

Banken sind bei fast jedem Aspekt wichtiger Geschäftsentscheidungen, die sich auf die Kundenzufriedenheit, die finanzielle Leistung, Infrastrukturinvestitionen und das Risikomanagement auswirken, auf fortschrittliche Analysen angewiesen.

Komplexe analytische Abfragen auf großen Datensätzen auf dem Mainframe können Rechenbudgets auffressen und Stunden oder Tage in Anspruch nehmen. Die Datenübertragung an einen anderen Ort – wie ein Cloud-Data-Warehouse– kann zu noch größeren Transportverzögerungen führen, was zu veralteten Daten und schlechten Qualitätsentscheidungen führt.

Garanti BBVA, die zweitgrößte Bank der Türkei, hat den IBM Db2 Analytics Accelerator for z/OS eingesetzt, der Abfrage-Workloads beschleunigt und den Mainframe-CPU-Verbrauch reduziert.

Die Trennung der Analyse-Workloads von den Anliegen und Kosten der Mainframe-Produktionsumgebung ermöglicht es Garanti, jede Nacht mehr als 300 Analyse-Batch-Jobs auszuführen, und ein Compliance-Bericht, der früher zwei Tage dauerte, dauert jetzt nur noch eine Minute.

Banken konkurrieren über ihre Fähigkeit, innovative neue Anwendungen und Serviceangebote für ihre Kunden bereitzustellen. Daher tragen flexible Devtest-Teams ständig neue Funktionen bei. Wir neigen natürlich dazu, diese als Frontend-Verbesserungen für Apps und API-Integrationenmit Cloud-Services zu verallgemeinern.

Aber warten Sie, fast jede dieser neuen Funktionen wird irgendwann den Mainframe erreichen. Warum nicht das Mainframe-Team als erstklassige Teilnehmer in der DevOps-Bewegung einsetzen, damit sie sich engagieren können?

Danske Bank beschloss, fast 1.000 interne Mainframe-Entwickler in eine firmenweite DevOps-Transformation einzugliedern, indem sie die IBM Application Delivery Foundation for z/OS (ADFz) als Plattform für Funktion-Entwicklung, Debugging, Tests und Release-Management nutzte.

Sogar vorhandener COBOL- und PL/1-Code konnte in die CI/CD-Management-Pipeline aufgenommen, dann intuitiv innerhalb der Entwickler-IDEs geöffnet und bearbeitet werden. Hier gibt es kein Herumhantieren mehr mit Greenscreens. Die Danske Bank kann jetzt Angebote in der Hälfte der Zeit auf den Markt bringen, die sie früher benötigte.

Lesen Sie die Fallstudie der Danske Bank https://www.ibm.com/de-de/case-studies/danske_bank_as

Auch neuere Fintech-Unternehmen, die von Anfang an auf Cloud-Lösungen setzen, täten gut daran, zu überlegen, wie ihre eigenen Innovationen mit einer sich ständig verändernden hybriden Computerumgebung von Geschäftspartnern interagieren müssen.

Eine Transaktion über eine mobile App erreicht letztendlich doch globale Zahlungsnetzwerke, Aufsichtsbehörden und andere Banken – jede mit ihren eigenen Mainframe-Rechen- und Speicherressourcen, die hinter der Bearbeitung jeder Anfrage stehen.

Niemals wird es hier einen einzigen Weg geben, denn keine zwei Banken sind identisch und es gibt viele mögliche Transformationen, die auf dem Weg der Mainframe-Anwendungsmodernisierung vorgenommen werden können.

IT-Verantwortliche müssen irgendwo anfangen und Anwendungsfälle auswählen, die am besten zu ihren Geschäftsanforderungen und der Architektur der einzigartigen Anwendungslandschaft passen, in der der Mainframe eingesetzt wird.

Mehr erfahren Sie in den anderen Beiträgen dieser Serie:

• Teil 1: „Mainframe-Anwendungsmodernisierung jenseits des Bankwesens“
• Teil 2: „Zusammenarbeit (nicht Migration) nutzen, um Ihre Mainframe-Anwendungen mit der Cloud zu modernisieren“
• Teil 4: „Mainframe und die Cloud? Mit Open Source ist es einfach.“