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 kennt die Antwort schon: Wochen an Freigaben, wenn alles glatt läuft. Im schlimmsten Fall dauerte neue Infrastruktur bei der Allianz 12 bis 18 Monate — manuelle Genehmigungen, handgebaute Netzwerkkonfiguration pro Entity und eine 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 eigentliche Risiko. Sie tauchte nur auf keinem Dashboard auf.

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. Nicht Migrations-Meilensteine, nicht Cluster-Zahlen — sondern die Zeit zwischen der Anfrage einer Ingenieurin und ihrem ersten Deploy in die neue Umgebung. Diese Rahmung erzwingt Trade-offs, die man sonst vermeidet: Golden Paths statt Sonderlösungen, was hieß, Landesgesellschaften zu sagen, dass ihre individuellen Konfigurationen wegfallen. Einige dieser Gespräche waren lang. Die Wette der Plattform: Ein konformer Standard, der Tage dauert, schlägt ein maßgeschneidertes Setup, das ein Jahr dauert — und Engineers stimmen mit ihren Workloads ab.

FCP legte eine richtliniengesteuerte Boundary um sämtliche Allianz-Workloads: Public-Cloud-Flexibilität, Private-Grade-Compliance. Mehrere Cloud-Anbieter, fit-for-purpose je Entity, unter einer gemeinsamen Security-Baseline. Datensouveränität als Konfiguration statt als Ausnahmebehandlung — australische Kundendaten bleiben 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 still um sie herum bauen.

Das Muster, das ich unbedingt vermeiden wollte, ist das übliche: 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 — statt zu einem Review-Gate vor dem Launch. Der konforme Weg wurde der schnelle Weg. Nur unter dieser Bedingung wählen ausgelastete Engineers ihn freiwillig.

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 statt in Monaten in Tagen, über Self-Service-Templates und Infrastructure-as-Code.
• Der Betrieb wurde über mehrere Provider und 70+ Länder standardisiert.
• Engineering-Teams im ganzen Konzern erbten Best Practices als Voreinstellung — CI/CD, Observability, Golden Paths — statt als Wiki-Seite.
• 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 Paved-Road-Muster aus dieser Arbeit fließen in The AI-native Platform Playbook ein.