Die Allianz wechselt auf Linux

"Wir sind seit Ostern 2022 nicht mehr auf dem Mainframe. Das war eines der risikoreichsten und schwierigsten Projekte meiner Karriere," sagt Axel Schell, CTO der Allianz Technology, die sämtliche IT-Services weltweit für die Allianz Gruppe erbringt. Gemeint ist das Projekt "ABS goes Linux", in dem das gesamte Allianz Business System (ABS), also die IT-Kernanwendungen samt Datenbank in Deutschland, auf standardisierte x86-Server mit Linux-Betriebssystemen migriert wurden. Ein Novum in der Versicherungsbranche.

Im Büro des Managers gibt es ein Dashboard. Darauf werden Echtzeitdaten etwa zur Datenbankverfügbarkeit, Anwendungsstabilität und verarbeiteten Versicherungsfällen auf der neuen Infrastruktur angezeigt. "So funktioniert Transparenz heute. Alle sind immer auf dem aktuellen Stand und das bringt Geschwindigkeit in die Organisation," sagt Schell.

Für mehr spannende Strategien, Hintergründe und Best Practices abonnieren Sie unsere CIO-Newsletter.

Zudem sorgt das Setup für Vertrauen bei den internen Kunden, ergänzt Sebastian Pongratz, Senior Executive in Schells Bereich und für die Umsetzung des Projekts verantwortlich: "Jeder User in den Geschäftsbereichen - nicht nur die IT - kann auf das Dashboard zugreifen und sehen, dass es funktioniert."

Kernanwendungen bisher auf dem Mainframe

ABS umfasst alle Kernanwendungen des Geschäfts der deutschen Konzerngesellschaften. Darin sind die gesamten Bestände der Region konsolidiert. Pongratz: "Es ist die zentrale Kundenplattform, in der über 30 Millionen Verträge verwaltet werden, und der Kern des deutschen IT-Ökosystems. Dazu gehören alle Schnittstellen zur Sachbearbeitung sowie zu Kunden- und Vertriebsportalen."

Wenn ABS nicht funktionierten, könnten auch der Vertrieb, die Makler, der Innendienst und der Web-Bereich nicht arbeiten. Das gelte für alle Lines of Business mit Kranken-, Sach- und Lebensversicherungen.

Raus aus der Abhängigkeit

"Wir konnten mit dem Mainframe zwar von den Innovationszyklen der Hersteller profitieren, waren damit aber auch von ihnen abhängig," so Pongratz. Es fehlte an Skalierbarkeit sowie der Basis für neue Plattformen oder Programmiersprachen. Cloud-native Anwendungen anzubinden oder agil zu entwickeln, sei kaum möglich gewesen.

Daher entschied sich die Allianz-IT Mitte 2019 für ein "Replatforming", also die bestehenden Systeme vom Großrechner in eine neue Umgebung zu hieven und entsprechend anzupassen. Damit sollte die IT weniger abhängig von Lieferanten sein und mehr technische Möglichkeiten bekommen.

Operation am offenen Herzen

"Wir haben in der Planung Optionen ausgelotet, das System in Scheiben auf die neue Plattform zu heben. Aber das Herzstück, eine der größten Linux-basierten DB2-Datenbanken, die es gibt, lässt sich nur als Ganzes migrieren," berichtet Pongratz. Um so eine "Operation am offenen Herzen" vorzubereiten, wählte Allianz Technology einen iterativen Ansatz.

Das Team um den IT-Manager kannte die Ziel-KPIs der neuen Umgebung. Die Performance und die automatisierten Prozesse des Mainframes sollten auch unter Linux zur Verfügung stehen. "Zudem hatten wir ein Mengen-Thema. Es musste alles so funktionieren wie vorher und gleichzeitig Raum für Wachstum in den kommenden Jahren vorhanden sein," so Pongratz.

Das Team definierte verschiedene Anforderungs-Cluster: Zielarchitektur, Anforderungen an die eingesetzten Produkte, Betriebs-KPIs zu Performance, Durchsatz und Automatisierungsquoten sowie die zugrundeliegenden Security-Standards.

"Davon ausgehend haben wir verschiedene Iterationen durchlaufen, um den Reifegrad schrittweise zu erhöhen und mit Providern gemeinsam deren Produkte an unsere Anforderungen anzupassen," erläutert Pongratz. Die mehrere Petabyte große Datenbank bot eine Verarbeitungsleistung in MIPS (Millionen Instruktionen pro Sekunde) im mittleren fünfstelligen Bereich auf dem Mainframe. So etwas sei bisher nicht auf DB2 unter Linux übersetzt worden.

Schrittweise Migration der Altanwendungen

In der ersten Phase galt es, die Stakeholder vom Nutzen des Projekts für das Business zu überzeugen. Dann wurden die Server bestellt.

Lesetipp: "Allianz Technology nutzt KI für den IT-Betrieb"

Die IT unternahm anschließend erste Gehversuche in der neuen Umgebung. Pongratz: "Wir haben ausprobiert, wie wir grundlegende ABS-Teile unter Linux lauffähig bekommen und wie sie sich unter Last verhalten." Das habe bei Applikationen begonnen und setzte sich mit der Integration der Datenbank fort bis hin zu spezifischen Komponenten wie den großen Batch für das monatliche Renewal.

Dann folgte eine erste Validierung. Relevante Fragen waren: Werden die gewünschten KPIs berücksichtigt? Kann der Betrieb für Testläufe vor dem Go-Live simuliert werden? Reichen die Kapazitäten und Durchsatzgeschwindigkeiten der beschafften Server und Storage-Systeme aus? Die Antwort lautete: Nein.

Rückschläge und Anpassungen

"Etwa 14 Monate vor dem Cut-Over haben wir realisiert, dass die bisher aufgebaute und bestellte Infrastruktur unser Zielsystem nicht trägt," berichtet Pongratz. Die Umgebung musste angepasst werden.

Die IT wechselte auf eine leistungsfähigere Infrastruktur und überarbeitete das gesamte Storage-Konzept. Pongratz: "Wir arbeiteten eng mit den externen Anbietern sowie deren Laboren zusammen und schickten ihnen Feature-Anforderungen, nicht nur zu Funktionen, sondern auch für Situationen im laufenden Betrieb." So sollten etwa mehrere tausend Prozesse im Datenbank-Cache bei Problemen in weniger als zehn Minuten herunter- und wieder hochgefahren werden können, ohne dass der User davon etwas merkt.

Auch Security-Produkte im Client-Server-Umfeld stießen an ihre Grenzen. Die abzusichernden Prozess-Volumina lagen um den Faktor zehn über dem, wofür die Lösungen ursprünglich gebaut waren. "Da mussten wir die Anbieter überzeugen, mit einzusteigen und ihre Software an unsere Umgebung anzupassen. Die können solche Features nun für ähnliche Größenordnungen auch anderen Kunden anbieten. Wir haben dafür gemeinsam mit ihnen die Pionierarbeit gemacht," ergänzt Schell.

Der Mainframe als Benchmark

Den Benchmark für solche KPIs setzte der Mainframe. "Dass die neue Umgebung ähnliche Performance liefert wie die alte, ist entscheidend für den Buy-in der internen Kunden," so Schell. Die neuen Features wurden in mehreren Iterationen getestet, angepasst und erweitert.

Zudem prüfte das IT-Team die Skalierbarkeit der neuen Plattform. Schell: "Wir müssen weitere Bestände migrieren und Kunden hinzugewinnen können. Also haben wir auch getestet, ob zusätzliche Volumina verarbeitet werden können." Über Wachstumssimulationen testete die IT, ob auch bei größeren Release-Wechseln oder kommenden Migrationen das System funktionsfähig bleibt.

"Wir haben etwa die Auslastung der Onlinekanäle gemessen, die Zeiten mit den meisten Zugriffen als Benchmark verwendet und geprüft, ob das neue System auch mit tausend zusätzlichen simulierten Sachbearbeitern zuverlässig arbeitet," so Pongratz.

Auch Batch-Prozesse wurden so geprüft, beispielsweise hinsichtlich der Lastspitzen im saisonalen Geschäft. Die KPIs dafür waren etwa die DB2-Zugriffe pro Sekunde, die in der Linux-Datenbank simuliert wurden. Gemessen wurde an jedem Tag eines Monats, um alle Szenarien abzudecken.

Parallel dazu wurde das Target Operating Model der neuen Umgebung eingeführt. In Deutschland, Indien und Ungarn baute die Allianz-IT Experten-Teams auf, um das neue ABS zu betreiben.

Die heiße Phase

Rund vier Monate vor dem angesetzten Termin für die Migration stoppte das Team die Weiterentwicklung der Produkte. Die bis dato erarbeiteten Versionen wurden für den Wechsel vorbereitet und nur noch durch einzelne Fixes verändert. Auf dieser Basis startete die Dauerbetriebssimulation in den letzten Wochen bis zum Stichtag.

Zum Video: Die Allianz wechselt auf Linux

In dieser Phase wurde etwa das Konzept zur Datenbankreorganisation samt Backups in den nächtlichen Ruhephasen überarbeitet. "Es lief nicht so schnell wie geplant. Also mussten wir es acht Wochen vor dem Go-Live anpassen," erinnert sich Pongratz.

Die Migration selbst wurde bewusst auf das Osterwochenende 2022 gelegt. "So hatten wir vier Tage Zeit für den Wechsel und Luft, um eventuelle Probleme zu lösen. Am Ende hat es 48 Stunden gedauert, den kompletten Datensatz zu übertragen," so Pongratz. Der gesamte Bestand aus dem Mainframe musste konvertiert, fachlich geprüft, bereinigt und auf Linux migriert werden.

Um für Probleme gewappnet zu sein, mussten zudem Logistik und Kommunikation vorbereitet werden. "Für den absolut schlechtesten Fall, in dem alle unsere im Vorfeld implementierten Absicherungen versagen, hatten wir den Roll-Back auf das alte System vorbereitet," sagt Pongratz. Schell ergänzt: "Wir hatten 1.000 Mitarbeiter im Einsatz, um in allen Bereichen zu testen, inklusive Agenturen und Makler." Zudem sei die Bankenaufsicht Bafin informiert worden.

Aufwand und ROI

Das Kern-Projektteam bestand aus rund 500 Mitarbeiterinnen und Mitarbeitern. Darüber hinaus arbeiteten etwa 3.000 Personen zeitweise in verschiedenen Phasen mit. Das Budget belief sich auf einen niedrigen dreistelligen Millionenbetrag.

Nach drei bis vier Jahren soll sich das Projekt amortisiert haben. Schell: "Wir betreiben die Plattform nun seit einem Jahr und sehen genau, was sie im Vergleich zum Mainframe kostet. Wir sparen im Betrieb einen zweistelligen Millionenbetrag ein," sagt Schell.

Vertrauen im Business wurde laut dem CTO erreicht, indem alle relevanten Transaktionen eines Users aus einem Fachbereich vorher und nachher gemessen wurden. "Im Test vor dem Go-Live haben wir gezeigt, dass die neuen Prozesse in den gewünschten Bereichen performant sind," so Schell. Die neue Plattform sei in kurzer Zeit bei jeder Transaktion nachweislich schneller gewesen als der Mainframe.

Die moderne Architektur und der Zugriff auf aktuelle Tools fördern laut Pongratz die Innovationskraft des Unternehmens. Ressourcen können nun dynamischer genutzt und einfacher allokiert werden. Entwickler müssen nicht mehr auf Batch-Jobs warten.

Auf die übergeordnete IT-Strategie zahlt das Projekt ebenfalls ein. Schell will auch Applikationen außerhalb von ABS konsolidieren und Legacy-Systeme abschalten: "Es ist zudem die Vorstufe für die Cloudifizierung der Umgebung. Wir haben einen sehr stabilen Betrieb erreicht und überlegen uns nun, ob und wie wir sie in die Cloud migrieren." Allerdings müssten dazu die gängigen Cloud-Hyperscaler erst noch passende Lösungen entwickeln, die die Performance-Anforderungen des Systems abbilden.

Die technischen Herausforderungen

"Neben der technischen Herausforderung war das auch ein großes People-Thema," berichtet Pongratz. In der Mainframe-Welt hatte die Allianz viel Know-how über die Applikationen aufgebaut, das essenziell für die Zielplattform war. Dieses Wissen musste erhalten bleiben.

Daher wurde das bestehende Team um Experten für die Zielplattform ergänzt. Die Kollegen aus der "alten Welt" wurden weitergebildet, um sie und ihre Expertise in die Linux-Umgebung mitzunehmen.

"Change-Management war ein großes Thema. DB2 auf dem Mainframe ist nicht DB2 auf x86," ergänzt Schell. Es gab Angst unter den Mitarbeiterinnen und Mitarbeitern, die Jahrzehnte auf dem Mainframe gearbeitet hatten. "Wenn man das nicht gut managet, kann das ein Projekt torpedieren."

Daher wurde die Belegschaft früh im Projekt einbezogen. "Uns ist es gelungen, die ganze Organisation auf ein Ziel einzuschwören und klarzumachen, dass jede Person wichtig für die neue Welt sein wird," sagt Pongratz. Die Kollegen wurden in Schulungen oder gemeinsam mit internen und externen Experten weitergebildet.

Zudem wurden Führungskräfte wie Abteilungs- und Teamleiter für Teilprojekte verantwortlich gemacht. Pongratz: "So hatten sie nach dem Motto 'you build it, you run it' ein eigenes Interesse, ihre Mitarbeiter mitzunehmen." Schell ergänzt: "Das Projekt hat in der Allianz in Deutschland alle betroffen, weil jeder mit ABS arbeitet, das System hat 300 Schnittstellen."

In den Projektphasen hat es auch mal geknirscht, wie Pongratz einräumt "Man muss aufpassen, dass man auf Linux nicht den Mainframe nachbaut." Gewisse Mechanismen müssten zwar in die neue Welt überführt werden, funktionierten dort jedoch anders. Daher war es etwa in der Qualitätssicherung wichtig, zu prüfen, ob die Anwendungen Linux-nativ mit Blick auf die Cloud gebaut wurden und nicht nach Legacy-Prinzipien.