Cloud-Transformation bei Allianz: Aufbau der internen Cloud Platform (FCP)

Eine Senior-Ingenieurin braucht eine Testumgebung vor dem Freitags-Release. Sie legt das Ticket an und wartet, denn genau das hat das Ticket immer bedeutet: Wochen an Freigaben, wenn alles glatt läuft. Im schlimmsten Fall dauerte neue Infrastruktur bei der Allianz 12 bis 18 Monate, zwischen manuellen Genehmigungen, handgebauter Netzwerkkonfiguration pro Gesellschaft und einer Warteschlange, die kein einzelnes Team verantwortete.

Das Warten war nur die Hälfte des Schadens. Wer wartet, baut Workarounds: lokale Setups, die nicht zur Produktion passen, geteilte Server ohne Verantwortlichen, Deployments am Genehmigungsprozess vorbei. Für einen der größten Versicherer der Welt, der in jeder Jurisdiktion regulierte Finanzdaten verarbeitet, war diese Schatten-IT das größere Risiko, und kein Dashboard zeigte sie.

Ich kam als Technical Product Owner für die Future Cloud Platform (FCP) an Bord, und die Entscheidung, die alles Weitere geprägt hat, war die Wahl der Messgröße. Ich nahm die Zeit zwischen der Anfrage einer Ingenieurin und ihrem ersten Deploy in die neue Umgebung. Diese eine Zahl erzwingt Trade-offs, die ein Meilensteinplan vermeiden lässt. Golden Paths ersetzten Sonderlösungen, und das hieß, Landesgesellschaften zu sagen, dass ihre individuellen Konfigurationen wegfallen. Einige dieser Gespräche waren lang. Die Wette: Ein konformer Standard, der in Tagen bereitsteht, setzt sich gegen ein maßgeschneidertes Setup durch, das ein Jahr dauert, und die Engineers zeigen ihre Präferenz dadurch, wohin sie ihre Workloads legen.

FCP legte eine richtliniengesteuerte Grenze um sämtliche Allianz-Workloads: die Flexibilität der Public Cloud mit der Compliance einer Private Cloud. Mehrere Cloud-Anbieter, je Gesellschaft passend gewählt, unter einer gemeinsamen Security-Baseline. Datensouveränität war eine Frage der Konfiguration, also bleiben australische Kundendaten in Australien. Darunter lief das Platform Engineering auf Kubernetes, Helm und Argo. Meine Schicht war die darüber: die Contracts, Defaults und Golden Paths, die entscheiden, ob Engineers eine Plattform annehmen oder um sie herum bauen.

Das Muster, das ich unbedingt vermeiden wollte, kennt jeder: Die Architektur steht seit Monaten, dann prüfen Security und Compliance am Ende und finden strukturelle Probleme. Also saßen IT, Security und Compliance von Anfang an in der Plattform-Governance, und ihre Anforderungen wurden zu Pipeline-Checks: automatisierte Audits, DSGVO-konforme Datenhaltung, regionenspezifisches Hosting. Engineers unter Termindruck wählen den konformen Weg, wenn er auch der schnelle ist, also mussten die Checks in die Pipeline, wo es nichts kostet, sie einzuhalten.

Die Migration lief durchgehend parallel auf On-Premise und Cloud, geschäftskritische Systeme blieben jederzeit verfügbar. Arbeit, die vorher 12 bis 18 Monate gedauert hätte, war in vier Monaten abgeschlossen, ohne Downtime.

• Standard-Umgebungen kamen in Tagen statt in Monaten, über Self-Service-Templates und Infrastructure-as-Code.
• Der Betrieb wurde über mehrere Provider und 70+ Länder standardisiert.
• Engineering-Teams im ganzen Konzern bekamen CI/CD, Observability und Golden Paths als Plattform-Defaults.
• Die Plattform trägt heute die Enterprise-AI-Workloads der Allianz, darunter den Enterprise Knowledge Assistant mit über 90.000 verarbeiteten Textabsätzen im Kundenservice.

Die Self-Service- und Golden-Path-Muster aus dieser Arbeit fließen in The AI-native Platform Playbook ein.