Key Takeaways
- Die Umstellung wurde durch schrittweise Entkopplung vorangetrieben, ohne das bestehende System vollständig zu ersetzen.
- Ein Echtzeit-Datensystem auf Basis von CDC ersetzte den direkten Zugriff auf den Mainframe.
- Statt REST wurden mit GraphQL zahlreiche BFF-Schichten entfernt und so Flexibilität sowie Wartbarkeit verbessert.
- Mit einer domänenorientierten Teamstruktur (Team Topologies) wurden Verantwortlichkeiten und Ownership der Teams klar definiert.
- Durch schrittweise Deployments und Automatisierung wurde das System risikofrei umgestellt und stabil Mehrwert geliefert.
Einführungsbeispiel: Die Hälfte des Systems überstand sogar einen Ausfall
Es kam zu einem Mainframe-Ausfall, doch dank der Cloud-basierten Streaming-Architektur funktionierte die neue UI weiterhin normal.
Auch wenn das bestehende System ausfiel, hielt das neue System die Kundenerfahrung aufrecht und bewies seine Resilienz.
Kernstrategie: Mehrschichtige Entkopplung (Decoupling)
- Domain-Driven Design (DDD): Das Mainframe-zentrierte Modell wurde in ein businessfreundliches Modell überführt
- Team Topologies: Umstellung auf funktionsorientierte Teamorganisation
- Event-basierte Architektur: Reduzierung der Kopplung zwischen Systemen durch asynchrone Kommunikation
- Change Data Capture (CDC): Erkennung von Datenänderungen in Echtzeit zur Verbindung von Legacy- und Neusystem
Frühere Struktur: Unified Web Portal 1.0
Verschiedene Mainframe-Daten wurden per ETL integriert und über eine SQL-Datenbank sowie SaaS bereitgestellt,
doch es traten Probleme wie fehlende Echtzeitfähigkeit, sinkende Datenqualität und direkte Mainframe-Aufrufe auf.
Probleme
- Datenverzögerungen durch ETL
- Unelastische synchrone Anbindung an den Mainframe
- Unzählige erzeugte BFF-APIs
- Engpässe und Release-Verzögerungen durch die Organisationsstruktur
- Bei stark ansteigendem Traffic führte Mainframe-Überlastung zum Ausfall des gesamten Service
Neue Zielsetzung
Technische Ziele: Entkopplung von Mainframe und Web, Entfernung des BFF, Sicherstellung der Teamautonomie
Business-Ziele: Weniger Anfragen im Callcenter, geringere Lizenzkosten, höhere Kundenzufriedenheit
Überblick über die neue Architektur
- Der Mainframe bleibt weiterhin das System of Record
- CDC → Kafka → Domänen-DB (CosmosDB)
- GraphQL + REST API → BFF → UI
- Event-basierte Struktur und Message Broker verbinden alle Komponenten
Schritt 1: Change Data Capture
- Aufbau eines Systems of Reference durch Echtzeit-Datenstreaming
- Mainframe → Kafka → Transformation → Domänen-DB → Bereitstellung per API
- Flexible Datenstruktur, die nicht vom Mainframe-Schema abhängig ist
Schritt 2: Domain-Driven Design + GraphQL
- Definition des Domänenmodells mit DDD (Entity, Command, Event)
- Aufbau jeder Domäne als GraphQL-Knoten, Erzeugung eines Supergraphen per schema stitching
- Unterstützung einer optimierten Query-Struktur, die nur die benötigten Daten abfragt
Veränderung der Organisationsstruktur: Team Topologies
- Neustrukturierung in funktionsorientierte stream-aligned Teams
- Komplexe Bereiche (z. B. Mainframe-Integration) werden von spezialisierten Teams betreut
- Betrieb von Enablement-Teams zur technischen Unterstützung
Event-basierte Erweiterung: Interne Domänen-Events + Saga-Pattern
- Das Outbox-Pattern erzeugt Events bei Änderungen in der Domäne
- Eine Parallel Saga synchronisiert Mainframe-Aufgaben und CDC
- Aufbau von Workflows auf Basis von State Machines → geeignet auch für komplexe Flows
Herausforderungen
- Für die Einführung einer Event-basierten Struktur war ein Umdenken innerhalb der Organisation nötig
- Wegen der asynchronen Struktur ist Observability unverzichtbar
- Mainframe-Batch-Jobs → verursachen Überlastung der CDC-Pipeline
- Komplexität beim Management von GraphQL-Schemas und Überlegungen zur Einführung eines federated approach
- Querschnittsthemen wie Authentifizierung/Logging werden über separate Pakete und Automatisierung verwaltet
Release-Strategie: Release Train + Feature Flag
- Jedes Team deployt unabhängig, die Integration erfolgt im Deployment-Repository
- Mit Kustomize wird eine umgebungsspezifische Deployment-Pipeline aufgebaut
- Feature Flags trennen funktionale und Security-Releases, während trunk-based Development beibehalten wird
Einsatz einer hybriden Architektur
- UWP 1.0 und UWP 2.0 laufen parallel, während die schrittweise Umstellung erfolgt
- Per Edge Routing werden User-Anfragen schrittweise auf das neue System umgeleitet
Fazit: Aufbau einer evolvierbaren Plattform
- Vollständige Entkopplung von Frontend und Mainframe
- Mehr Geschwindigkeit und Stabilität durch teamzentrierte Struktur
- Verbesserte Kundenzufriedenheit und geringere Betriebskosten
- Flexible Grundlage geschaffen, die künftig sogar den Austausch des Mainframes ermöglicht
1 Kommentare
Die schrittweise Verbesserung und die schrittweise Extraktion von Microservices sind sehr wichtig ... Wenn ich solche Artikel lese, denke ich, wie wichtig und beeindruckend der PM ist, der ein solches Projekt leitet. So vieles zu managen, ist echt heftig.