Zum Inhalt springen
Zurück zu Insights
Betrieb11 Min. Lesezeit

Sidecar-Cores und Strangler-Fig-Muster: Die reale Architektur progressiver Bankenmodernisierung

Das Sidecar-Core-Muster eliminiert kein Migrationsrisiko. Es verschiebt einen einmaligen Cutover und ersetzt ihn durch ein kontinuierliches Reconciliation-Erfordernis, das für die Dauer des Parallel-Laufs bestehen bleibt, der in den meisten Bankenmodernisierungsprogrammen zwei bis fünf Jahre beträgt. Banken, die den Sidecar als kontrollierten Piloten behandeln und Reconciliation als spätere Phase hinzufügen, entdecken das Problem konsistent in der falschen Reihenfolge: Reconciliation-Lücken treten auf, nachdem Daten bereits monatelang über zwei Systeme hinweg unterwegs waren.

40 % der Banken verfolgen Sidecar-Core-Strategien Mitte 2026, mit einer Prognose von 70-80 % bis 2028. 85 % der Finanzinstitutionen berichten Pläne für schwere Core-Transformationsinvestitionen (KPMG European Banking Outlook 2026). Die Branche hat akzeptiert, dass Big-Bang-Replacement zu riskant ist. Ob ein Sidecar betrieben werden soll, ist keine offene Entscheidung mehr. Was zählt, ist, ob die Sidecar-Architektur die Reconciliation-Infrastruktur enthält, die notwendig ist, um zwei Finanz-Cores parallel zu betreiben, ohne irrekonzilierbaren Zustand zu akkumulieren.

Warum Big-Bang-Replacement gescheitert ist

Die TSB-Migration von 2018 ist die kanonische Referenz. TSB versuchte, 5,2 Millionen Kunden von der Lloyds Banking Group-Plattform auf seinen neuen Proteo4UK-Core an einem einzelnen Wochenende zu migrieren. Die Migration produzierte einen 18-tägigen Ausfall, der 1,9 Millionen Kunden betraf, sperrte Kunden aus ihren eigenen Konten aus, legte einigen Kunden die Transaktionsdaten anderer Kunden offen und kostete TSB letztendlich über GBP 330 Millionen in Remediation, Kompensation und regulatorischen Strafen. Die UK FCA und PRA verhängten 2023 zusätzliche Strafen in Höhe von GBP 48,65 Millionen.

Die strukturelle Ursache war kein einzelner Bug. Es war die Unmöglichkeit, in einer Testumgebung die vollständige Verhaltensgleichheit zweier Systeme gegen fünf Jahre Produktionsdaten, Kundenstatus und Edge-Case-Transaktionshistorie zu validieren. TSB hat die Migration ausgiebig getestet. Die Produktionsumgebung enthüllte Interaktionen, die keine Testmatrix vorhergesehen hatte.

Jeder großangelegte Core-Banking-Replacement, der einen einzelnen Wochenend-Cutover versucht hat, hat dasselbe Kategorie von Problem gesehen. Das Verhalten des Legacy-Systems ist nicht vollständig dokumentiert. Das Verhalten des neuen Systems unter Produktionslast unterscheidet sich von seinem Verhalten unter Testlast. Der Kundenstatus im Moment des Cutovers enthält Edge-Cases, die die Vor-Migration-Tests nicht abgedeckt haben.

Sidecar-Architektur vermeidet den einzelnen Wochenend-Cutover. Sie führt eine andere Klasse von Problem ein.

Das Split-Brain-Problem

Wenn zwei Cores gleichzeitig gegen überlappende Kundendaten operieren, werden sie zu potenziellen Quellen widersprüchlicher Wahrheit. Kundin Alice hat ein Konto im Legacy-Core (wo ihre Dauerauftragsmandate, Daueraufträge und historische Transaktionsdaten leben) und im modernen Sidecar (wo ihre neuen Konten und neuen Produkte leben). Wenn Alices Gehalt eingezahlt wird, geht es auf das Legacy-Konto. Wenn sie ein Abonnement mit dem neuen Produkt bezahlt, geht es auf das Sidecar-Konto. Ihr verfügbares Gesamtguthaben ist die Summe beider, aber keiner der Cores kennt das vollständige Bild.

Das Split-Brain-Problem hat drei Dimensionen.

Guthaben-Sichtbarkeit. Die Kundin sieht ein Guthaben, das davon abhängt, welches System-Konto sie abfragt. Kundenservice-Agenten müssen beide Systeme abfragen, um zu antworten "wie hoch ist mein Gesamtguthaben?" Jede kunden-facing Guthabenabfrage, die beide Systeme berührt, erfordert einen Join-Operation über zwei Cores, die möglicherweise ihren Status im Moment der Abfrage nicht synchronisiert haben.

Transaktionshistorie. Eine Kundin, die eine Abbuchung bestreitet, muss ihre vollständige Transaktionshistorie rekonstruierbar haben, unabhängig davon, welcher Core sie verarbeitet hat. Ein Audit-Trail, der sagt "Ihre Transaktionen vor [Datum] sind im Legacy-System; Ihre Transaktionen nach [Datum] sind im neuen System", ist keine vollständige Transaktionshistorie. Es ist eine Partitionierung zweier unvollständiger Records.

Compliance-Status. CDD-Datensätze, AML-Flags, PEP-Designationen und Sanktions-Screening-Ergebnisse müssen über beide Cores konsistent sein. Wenn eine Kundin im Legacy-System markiert ist, aber der Sidecar dieses Flag nicht erhalten hat, kann der Sidecar Transaktionen verarbeiten, die das Legacy-System blockiert hätte. AMLD5 Artikel 14 verlangt, dass CDD-Ergebnisse konsistent über alle Produktlinien angewendet werden, eine Anforderung, die strukturell verletzt wird, wenn die zwei Cores ihren Compliance-Status nicht in Echtzeit teilen.

Reconciliation als erstklassige Architekturkomponente

Der korrekte Ansatz ist, Reconciliation als strukturelle Komponente der Sidecar-Architektur zu behandeln, nicht als operativen Prozess, der nach dem Deployment hinzugefügt wird.

Event-sourced Synchronisation. Jeder Statuswechsel in einem der Cores wird als Event in ein geteiltes Event-Log veröffentlicht. Das Event-Log ist die autoritative Aufzeichnung dessen, was passiert ist, in welcher Reihenfolge. Der Legacy-Core und der moderne Sidecar konsumieren beide dieses Event-Log. Ihre Zustände sind von derselben Sequenz von Events abgeleitet. Reconciliation ist kein Vergleich zweier unabhängiger Zustände. Es ist die Verifikation, dass beide Cores dieselbe Event-Sequenz korrekt angewendet haben.

Das erfordert, dass beide Cores event-sourced Zustandsableitung unterstützen, was Legacy-Cores im Allgemeinen nicht tun. Der praktische Ansatz für Legacy-Systeme ist, Änderungen durch Change Data Capture (CDC) zu erfassen: das Transaktionslog der Legacy-Core-Datenbank zu monitoren und Statusänderungen in Events zu konvertieren. CDC führt Latenz ein (Sekunden bis Minuten) und erfordert sorgfältigen Umgang mit Legacy-Datenmodell-Eigenheiten: undokumentierte Felder, implizite Zustandsautomaten, die in Status-Spalten codiert sind, und Geschäftsregeln, die in Stored Procedures statt in Anwendungscode leben.

Unveränderlicher Audit-Trail über beide Cores. Jede von einem der Cores verarbeitete Transaktion muss in einem geteilten unveränderlichen Audit-Log mit einem gemeinsamen Korrelations-ID-Schema aufgezeichnet werden. Wenn eine Kundin fragt "was ist mit Zahlung X passiert?", muss die Antwort aus dem geteilten Log abrufbar sein, unabhängig davon, welcher Core sie verarbeitet hat. Das geteilte Log ist keine Reporting-Datenbank, die beide Cores periodisch aggregiert. Es ist ein Write-Ahead-Journal, in das beide Cores vor Ausführung von Statusänderungen schreiben.

Rollback-Fähigkeit auf Produktsegment-Granularität. Das Strangler-Fig-Muster migriert Kunden oder Produktsegmente inkrementell vom Legacy-Core zum modernen Sidecar. Wenn eine Produktsegment-Migration einen Verhaltensunterschied aufdeckt, wo der moderne Core einen spezifischen Edge-Case anders handhabt als der Legacy-Core, muss die Architektur das Zurückrollen dieses Segments auf den Legacy-Core ohne Datenverlust unterstützen.

Rollback erfordert, dass der moderne Core-Zustand eine Obermenge dessen ist, was der Legacy-Core für dieselben Transaktionen gehabt hätte. Wenn der moderne Core Transaktionen verarbeitet hat, die der Legacy-Core nicht repräsentieren kann (weil das Legacy-Datenmodell den neuen Kontentyp nicht unterstützt, oder die Legacy-Workflow-Engine die Event-Sequenz nicht replayen kann), ist Rollback nicht möglich. Das muss vor der Migration jedes Segments verifiziert werden, nicht während des Rollback-Versuchs entdeckt werden.

Das Strangler Fig auf Produktgranularität

Das Strangler-Fig-Muster, benannt nach dem Feigenbaum, der um einen Wirtbaum herumwächst und ihn schrittweise ersetzt, migriert Funktionalität inkrementell. Im Core-Banking ist die effektivste Granularität für das Strangler Fig das Produktsegment: ein Produkttyp nach dem anderen migrieren, beginnend mit der Neukundenakquise (neue Kunden bekommen den modernen Core; bestehende Kunden bleiben auf dem Legacy-Core, bis explizit migriert).

Die Produktsegment-Migration bei Neukundenakquise hat einen spezifischen Vorteil: neue Kunden haben keinen historischen Status im Legacy-Core. Es gibt keine Kundendaten zu migrieren, keine Transaktionshistorie zu reconcilen, keine Dauerauftragsmandate zu transferieren. Die Reconciliation-Last für Neukunden-Segmente ist auf die Verifikation begrenzt, dass der Sidecar-Core Produkte korrekt verarbeitet, die der Legacy-Core nie verarbeitet hat.

Die Reconciliation-Last steigt, wenn bestehende Kundensegmente migriert werden. Jeder bestehende Kunde bringt historischen Status mit: Transaktionshistorie, Produktkonfigurationen, Dauerauftragsmandate, Daueraufträge, CDD-Datensätze, AML-Flags und laufende Prozesse (ausstehende Zahlungen, offene Dispute, geplante Überweisungen). Die Migration bestehender Kunden erfordert:

  1. Extraktion des vollständigen aktuellen Status jedes Kunden aus dem Legacy-Core.
  2. Verifikation, dass das Datenmodell des modernen Cores jedes Element dieses Status ohne Verlust repräsentieren kann.
  3. Transformation des Legacy-Status in das Format des modernen Cores.
  4. Laden des transformierten Status in den modernen Core.
  5. Parallel-Betrieb beider Cores für eine Verifikationsperiode, Vergleich der Outputs für dieselben Inputs.
  6. Cutover des kunden-facing Traffics auf den modernen Core.
  7. Retention des Legacy-Cores im Read-Only-Modus für eine definierte Periode, um Dispute zu handhaben, die historische Daten referenzieren.

Schritt 5 ist, wo die meisten Programme den Aufwand unterschätzen. Die Verifikationsperiode erfordert die Generierung identischer Transaktionseingaben gegen beide Cores und den Output-Vergleich mit ausreichender Coverage, um zuversichtlich zu sein, dass Verhaltensgleichheit über Edge-Cases hält, nicht nur für den Happy Path, sondern für Fehlerbedingungen, R-Transaktionen, konkurrierende Updates und regulatorisch-getriggerte Events. Das kann nicht durch das Ausführen einer Test-Suite erfolgen. Es erfordert das Simultane-Replay von Produktionstraffic-Patterns gegen beide Systeme.

Der 14%-CAGR-Kontext

Cloud-Deployment im europäischen Bankensektor wächst mit 14 % CAGR (KPMG 2026). SaaS- und gehostete Core-Banking-Modelle haben 67,5 % Marktanteil erreicht. Der Markt verschiebt sich von Vendor-Locked-Systemen der dritten Generation hin zu composable Cores der vierten Generation mit offenen APIs und cloud-native Deployment-Modellen.

Diese Verschiebung bedeutet, dass die meisten Banken, die aktuell Sidecar-Programme betreiben, moderne Cores evaluieren, die spezifisch für Cloud-Deployment gebaut wurden, mit Event-sourced-Architekturen, ISO 20022-native Datenmodellen und Standard-API-Verträgen. Die Reconciliation-Herausforderung ist niedriger, wenn beide Cores dieselbe Datensprache sprechen: wenn die Transaktionen des Legacy-Cores mit ISO 20022 BankTransactionCodes klassifiziert werden können und der moderne Core dieselbe Klassifikation nativ verwendet, ist die Reconciliation-Match strukturell statt heuristisch.

Die Reconciliation-Lücke ist am breitesten, wenn der Legacy-Core proprietäre Transaktionscodes, proprietäre Konten-Identifier und proprietäre API-Verträge verwendet, und der moderne Core ISO-Standards durchgängig nutzt. Jeder Reconciliation-Match zwischen diesen zwei Systemen erfordert eine Übersetzungsschicht, und jede Übersetzungsschicht ist eine Wartungslast und eine potenzielle Mismatch-Quelle.

Trade-offs

Progressive Modernisierung via Sidecar führt Kosten ein, die Big-Bang-Replacement vermeidet, und vermeidet Kosten, die Big-Bang-Replacement schafft.

Laufender operativer Overhead. Zwei Cores in Produktion zu betreiben, verdoppelt die operative Oberfläche: Monitoring, Incident-Response, Kapazitätsplanung und Security-Patching müssen beide Systeme abdecken. Für Institutionen, die bereits unterbesetzt für Core-Banking-Operations sind, die operative Oberfläche zu verdoppeln, ohne Headcount zu erhöhen, schafft Risiko.

Konsistenzfenster. Event-sourced Synchronisation führt ein Latenzfenster zwischen einem Statuswechsel in einem Core und seiner Propagation zum anderen ein. Während dieses Fensters können die zwei Cores unterschiedliche Zustände für dieselbe Kundin reporten. Für Compliance-Zwecke muss das Fenster begrenzt und dokumentiert sein: Regulatoren erwarten von Institutionen, dass sie die maximale Verzögerung in ihrer Dual-Core-Architektur kennen und deren Impact auf Compliance-Verpflichtungen bewertet haben.

Datenmodell-Inkompatibilitäten. Legacy-Cores wurden mit Datenmodellen gebaut, die ISO 20022, PSD2 und GDPR vorwegnahmen. Die Migration von Kundendaten von einem Legacy-Modell zu einem modernen erfordert den Umgang mit fehlenden Feldern (GDPR-Consent-Records, die der Legacy-Core nicht trackt), strukturellen Mismatches (proprietäre Transaktionscode-Enumerationen, die nicht sauber auf ISO 20022-Codes mappen) und semantischen Ambiguitäten (Status-Spalten, die Geschäftsregeln codieren, die nirgendwo mehr dokumentiert sind).

Fernel Context

Fernels Architektur ist von ihrer initialen Layer-Dekomposition an für Sidecar-Deployment ausgelegt. Die drei streng isolierten Layer (die Ledger-Engine, die Orchestrierungs-Engine und die Domain-Layer) operieren unabhängig. Eine Bank, die einen Sidecar betreibt, kann Fernels Ledger-Engine für neue Produktsegmente deployen, während sie den Legacy-Core für bestehende Kunden behält, und die zwei über eine Event-sourced Synchronisationsschicht verbindet, die in beide das Legacy-Transaktionslog und Fernels append-only Journal schreibt. Die Reconciliation-Infrastruktur ist das Event-Log, kein periodischer Batch-Job: jeder Statuswechsel in einem der Systeme ist ein Journal-Eintrag mit einer Korrelations-ID, zu jedem Zeitpunkt abfragbar.

Weiterlesen: Die Architektur eines Financial Operating Systems | Echtzeit-Reconciliation | Workflows, Durable Execution Engine

Quellen:

  • KPMG, European Banking Outlook 2026: 40% Sidecar-Adoption Mitte 2026, 70-80% prognostiziert bis 2028; 85% planen schwere Transformation; 14% CAGR Cloud-Deployment; 67,5% SaaS/hosted Marktanteil
  • TSB-Migrations-Fehlschlag, April 2018: GBP 330 Millionen Gesamtkosten, 1,9 Millionen Kunden betroffen, 18-tägiger Ausfall. UK FCA/PRA Enforcement Action und GBP 48,65 Millionen Strafe (2023)
  • ThoughtWorks, "Kill your core: The banking revolution you didn't see coming": Coreless-Banking-Architektur-Prinzipien
  • AMLD5, Richtlinie 2018/843, Art. 14 (Timing and scope of CDD verification, consistency requirement)
  • Strangler Fig Pattern: Martin Fowler, "StranglerFigApplication" (2004), inkrementelle Migration via paralleler Systembetrieb
  • ISO 20022 BankTransactionCode External Code Sets: die Daten-Sprachbrücke für Dual-Core-Reconciliation