Streaming und Mainframe: alte Hardware-Architektur trifft moderne Software
Seite 2: Streaming Erfolgsgeschichten
Können Sie uns einige typische Beispiele für Streaming mit dem Mainframe nennen, die Ihre Kunden schon erfolgreich realisiert haben?
Die Liste möglicher Anwendungen ist lang. Dazu gehören eine Rundumsicht auf Kunden und ihr Verhalten (360-Grad-Kundensicht), Betrugsvorbeugung und -erkennung, im Retail das Onboarding von Verkäufern, die Abstimmung von Kundendaten, die Echtzeit-Nutzung von Verkaufsdaten einzelner Standorte oder die Rationalisierung der Lieferkette.
Neben vielen fachlichen Use Cases gibt es auch technische Gründe, darunter die IT-Modernisierung durch die Entlastung des Mainframes – das sogenannte Mainframe-Offloading. Die Streaming-Plattform ermöglicht hierbei die Korrelation von Mainframe-Daten mit ERP-Daten und neuen (non-Mainframe) Daten wie IoT-Sensor-Daten. So lassen sich mit dem Mainframe ganz neue Use Cases in cloud-nativen Umgebungen aufbauen.
Ganz aktuell durchläuft die Nord/LB eine IT-Transformation, in deren Verlauf sie mit Hilfe zunächst von On-Premises-Confluent und nun auch der Confluent-Cloud-Plattform die Daten einer neuen SAP-basierten Kernbankanwendung in das vorhandene Big-Data-System einbringt. Da das Big-Data-System schnell und unkompliziert Zugang zu den Confluent-Daten hat, können sich die Data Scientists auf die Erstellung ihrer Modelle konzentrieren.
Wie einfach oder wie kompliziert ist es im Vergleich zu anderen Plattformen, den Mainframe als Datenquelle für das Streaming zu nutzen?
Das kommt natürlich auf die Plattform an. Bei Confluent ist es auf vielfältige Weise möglich. So gibt es Konnektoren zu Db2 und IBM MQ. Wir können über Kafka Connect und MQ Source- und Sink-Connector Teile der Infrastruktur auf z/OS statt auf klassischem Linux laufen lassen. Das kann Leistung und Kosten optimieren. Dadurch lassen sich ganze Prozessketten von Ende zu Ende orchestrieren, zu denen auch Mainframes gehören.
Allerdings wird in vielen unserer Projekte auch Third-Party-Middleware, etwa IBM IIDR, eingesetzt, um den Mainframe anzubinden. Das gilt besonders, wenn Kunden kein MQ einsetzen, für das wir ja selbst eine Anbindung haben. Für Anbindungen an Nicht-Mainframe-Anwendungen wie Snowflake oder SAP liefern wir ebenfalls Konnektoren. Außerdem gibt es Toolkits, mit denen sich sogar Individualsoftware oder stark angepasste Standardsoftware einbinden lassen.
Oft sind die reinen Daten ja besser über die zugehörigen COBOL-, Assembler- oder PL/1-Programme nutzbar: Sind mit Confluent auch Mainframe-Programme als Datenquelle nutzbar? Falls ja: Worauf ist dabei zu achten? Falls nein: Warum (noch) nicht – oder ist das gar nicht sinnvoll?
Natürlich können wir nicht alles. Grundsätzlich lassen sich Anwendungen über Programmiersprachen wie Java oder C++ oder auch über Web-Service-Schnittstellen wie HTTP/REST anbinden. Wo möglich, werden existierende COBOL-, Assembler- oder PL/1-Anwendungen nicht mehr angefasst, weil Entwickler-Knowledge fehlt und solche Prozesse mit hohem Risiko behaftet sind.
Falls für den individuellen Fall vorhanden, benutzen wir Confluent-Konnektoren oder aber Mainframe-spezifische Third-Party-Middleware. Letztere ist in der Regel nötig, sobald Anwender kein MQ als Integrationsschnittstelle benutzen.
Integrations- und Migrationsprojekte auf dem Mainframe sind selten einfach. Dabei sollte man mit viel Fingerspitzengefühl vorgehen. Der Prozess ist bei aller technischen Hilfestellung auch organisatorisch anspruchsvoll. Es gibt unterschiedliche Methoden, je nachdem, wie diese Applikation aussieht. Beim reinen Lift-and-Shift oder Rehosting lässt sich die App einfach in einen Container packen und auf die neue Plattform, etwa die Cloud, verschieben. Das ist aber bei klassischen Mainframe-Apps, die über Jahrzehnte gewachsen sind, eher selten.
Beim Re-Enginieering werden manche Teile der Apps containerisiert und mit einer API-Schicht zur Kommunikation versehen, hier spricht man auch vom Wrapping. Das ist deutlich aufwändiger. Und schließlich kann man Applikationen komplett neu in einer modernen Architektur schreiben, das sogenannte Refactoring. Das ist in der Regel der aufwändigste Weg.
