Es ist das Jahr 2022 und wer glaubt, dass Mainframes in der IT keine Rolle mehr spielen, ist auf dem Holzweg. Viele Kernsysteme großer Unternehmen laufen auch heute noch auf solchen Systemen. Als Mainframe oder Host bezeichnet man leistungsfähige Großrechner, die viele Tausend Transaktionen gleichzeitig abwickeln können, aber technisch kaum auf einer modernen und vor allem verteilten Cloudinfrastrukturen betreibbar sind. Sie eignen sich sehr gut, um Millionen von Konten korrekt zu verwalten oder Transaktionen abzuwickeln und sind deshalb immer noch in der Finanzindustrie sehr präsent. Nach aktuellen Schätzungen werden circa 90 Prozent der Kreditkartentransaktionen heute immer noch durch Mainframes abgewickelt. 2019 konnte IBM mit seinen z15-Systemen seine Umsätze im Großrechnersegment sogar um mehr als 60 Prozent steigern.

Host-Hersteller freut dieser Umstand, da sie mit ihren Systemen und den zugehörigen MIPS-basierten Lizenzmodellen (MIPS: Million Instructions Per Second) eine Menge Geld verdienen. Dieser enorme Kostenblock ist einer der beiden Hauptgründe, warum viele Unternehmen ihre Hostsysteme lieber heute als morgen loswerden wollen. Es ist aber auch die mangelnde Flexibilität bei der Nutzung von Host-Daten in einer zunehmend servicegetriebenen Gesellschaft, die immer mehr Nutzer dazu zwingt, alte Strategien zu überdenken. Genau diese mangelnde Flexibilität ist neben den Kosten der fast noch wichtigere Grund, warum Finanzdienstleister fürchten, durch agile und bessere Angebote des Wettbewerbs abgehängt zu werden.

Wenn man wüsste, was man weiß

Die gute Nachricht ist, dass in der Regel alle Informationen auf einem Host vorhanden sind, die auch in der modernen Servicewelt einer Cloud benötigt werden. Dann ist doch alles gut: irgendwie ein modernes Frontend wie eine Handy-App oder ein Online-Banking-Portal auf die Kontodaten des Mainframes schauen lassen und schon ist alles live und in Farbe. Jedoch gelten diese Systeme nicht ganz zu Unrecht als recht unflexibel, wenn es um die schnelle Umsetzung von Services mit Near- bzw. Real-Time-Szenarien geht.

Taucht man etwas tiefer in deren Datenhaltung, sieht man, dass direkte Datenanbindungen erstens gar nicht so einfach zu realisieren sind und dass sie zweitens eine Menge Geld kosten, weil Verarbeitungen auf den Großrechnern häufig nach CPU-Verbrauch (MIPS – Million Instructions per Second) abgerechnet werden. An dieser Stelle ist Datensparsamkeit das Gebot der Stunde, was ein 360-Grad-Kundenerlebnis in Echtzeit erheblich erschwert. Zudem liegen Informationen häufig so vor, wie sie nur Host-Programme sinnvoll verarbeiten können. Das heißt, jede Abfrage von außen erfordert nicht nur den Zugriff auf die Host-Daten, sondern auch noch deren bedarfsgerechte Aufbereitung für einen sinnvollen Kontext. Das bedeutet am Ende noch mehr CPU-Verbrauch, nicht selten proprietäre Schnittstellen und dann auch noch mehrere Iterationen für identische Daten. Bevor also gleiche Daten teuer wieder und wieder abgerufen werden, kann es sich lohnen, sie einmalig auszuleiten und dezentralen Anwendungen und Datenbanken gebündelt zur Verfügung zu stellen. Von dort aus kann dann ohne CPU-Lizenzmodelle alles nach Belieben verarbeitet und auch in Mikroservice-Architekturen überführt werden, die besser zu modernen Apps und Webportalen passen als ein Host-Backend. Es wird demzufolge ein Datentransportmedium gebraucht, das neue Daten wie beispielsweise Umsätze oder Salden in die dezentrale Welt überführt und dort verfügbar macht. Und natürlich darf dabei nichts schiefgehen. Schließlich würden fehlende oder versehentlich mehrfach gelieferte Informationen zum Beispiel einen Kontostand verfälschen. Gerade der letzte Aspekt, die vollständige und konsistente Datenverarbeitung, ist leider häufig nicht die Stärke verteilter Cloudtechnologien und vieler Consultingunternehmen, die zu diesem Thema beraten. Ursprünglich stammen entsprechende Systeme häufig aus dem Big Data-/Analytics-Kosmos, wo die ACID-Transaktionalität eine eher untergeordnete Rolle spielt.

Mit Kafka Hostdaten als Service verfügbar machen

Das Ziel ist also klar: eine Entkopplung von zentralen und dezentralen Anwendungen und eine Neartime-Datenversorgung von Microservices für Apps und Portale und dadurch Mehrwerte für den Kunden. Ein Ansatz ist, mit Apache Kafka einen sicheren und skalierbaren Transport von Nachrichten zu organisieren. Dazu bringt das Kafka-Ökosystem die Schnittstellen bereits mit, um beteiligte Systeme zu verbinden, ohne sie in die Synchronität zu zwingen. Das heißt, der Ausfall eines Datenabnehmers führt nicht zu einem Rückstau in der Brennkammer des Mainframes.

Kafka kümmert sich also um die Serialisierung, Deserialisierung und den kompakten sowie sicheren Transport der Messages. Eine Host-Nachricht kann dadurch von vielen beliebigen Systemen oder Datenabnehmern gleichzeitig und nicht konkurrierende konsumiert werden. Ein Datenabnehmer abonniert (in Kafka: subscribe) gewissermaßen einen beliebigen Datenstrom (Kafka Topic: Daten einer bestimmten fachlichen Ausprägung).

Dabei hilft auch eine sogenannte zentrale Schema-Registry innerhalb der Kafka-Umgebung, die quasi den Schnittstellenvertrag zwischen Datenlieferant (hier der Host; bei Kafka: Producer) und Datenempfänger (bei Kafka: Consumer) abbildet. So können beispielsweise bestimmte Datenstrukturen oder auch Pflichtfelder definiert werden, ohne die eine weitere Verarbeitung durch Kafka nicht möglich ist. Des Weiteren bietet eine Schema-Registry die Möglichkeit, dass ein neuer Consumer (z. B. eine beliebige Fachanwendung) wie in einem Inhaltsverzeichnis nachlesen kann, welche Teile einer Nachricht für den eigenen fachlichen Anwendungsfall relevant sind. Kafka kann also die prozessierten Datenstrukturen und Inhalte für alle Interessenten exponieren. So wird ein Datenstrom für diverse Anwendungsfälle gleichzeitig und einfach nutzbar, ohne dass der Consumer notwendigerweise in einen Dialog mit dem anliefernden System treten müsste oder gar eigene Schnittstellen zwischen den Systemen erforderlich werden.

Wichtig bei diesem Ansatz ist, dass die Business-Logik bleibt, wo sie ist: auf dem Mainframe. Die Daten werden dort faktisch als Nebenprodukt für die Ausleitung aufbereitet und per Schema-Bekanntgabe sehr einfach abfragbar gemacht. So müssen dezentrale Anwendungen keine Business-Logik nachbauen wie zum Beispiel die Aufbereitung technischer Schlüsselinformationen. Diese Verarbeitungen bleiben auf dem Mainframe. Da die Aufbereitung der Daten Host-intern ohnehin stattfindet und die Übergabe an Kafka mittels UNIX-Systemservices keine zusätzlichen und kostenintensiven MIPS produziert, handelt es sich um ein sehr elegantes Verfahren, um die Daten auszuleiten.

Warum nicht einfach alles neu machen?

Dass technisch neue Lösungen mit 100 Prozent Cloudtechnologie so leistungsstark und performant sein können, wie es Amazon vormacht, mag schon richtig sein. Nur befinden sich Mainframe-Kunden in einer real existierenden IT-Welt. Die Versprechen einer ein-fachen Host-Ablösung durch einige Tech-Firmen sind an dieser Stelle deshalb genauso unbrauchbar wie zum Teil die Architekturvorschläge der Old-IT-Economy. Denn genauso wenig wie sich ein Host-Administrator mit Cloud-Architekturen auskennt, kennt sich der durchschnittliche Cloud-Architekt in der Host-Welt aus. Angesichts dieser technischen Lücken zwischen den IT-Welten sollte man sich fragen: Wer kann und will sich in den zumeist sehr sensiblen Unternehmensbereichen, in denen noch heute die Mainframes zu finden sind, einen vollständigen Greenfield-Ansatz erlauben? Mut und Wahnsinn liegen hier relativ eng beieinander und was mit einem Java-Programm in der Cloud vielleicht noch relativ einfach realisierbar wäre, ist mit dem Funktionsumfang eines Host-Systems nicht unbedingt die cleverste Idee.

Fazit:
Hostdaten mit Kafka in eine dezentrale IT-Infrastruktur zu übertragen, ist lediglich der erste Schritt in Richtung moderner Services. Neben der Technik ist die größte Herausforderung, den menschlichen Faktor bei solchen Projekten zu berücksichtigen. Hier treffen in der Regel Welten aufeinander und nicht alle Mitarbeiter in der IT sind begeisterte Anhänger von verteilten Architekturen und Cloud-Services.

Aber auch der längste Weg beginnt mit dem ersten Schritt und es bietet sich an, zunächst eine Brücke in die neue Welt zu bauen, als ein über die Jahre gewachsenes Großsystem, in einem Gewaltakt abzulösen. Eine weitere Herausforderung besteht darin, erfahrene IT-Berater in diesem Segment zu finden. Strategische Projekte dieser Art aus eigener Kraft und ohne externe Expertise zu stemmen, ist wohl den wenigsten Unternehmen möglich.