Die Sidecar-Architektur gilt als ein Ansatz, mit dem Banken ihre Legacy-Systeme schrittweise modernisieren können, ohne den stabilen Kern unmittelbar abzulösen. Drei Experten beschreiben in einem Beitrag des IT Finanzmagazin, wie sich durch die Kombination von Change Data Capture (CDC), APIs und Batch-Verfahren ein kontrollierter Übergang erreichen lasse – häufig im Zusammenspiel mit dem Strangler-Fig-Pattern.
Daten-Ownership und Architektur als Ausgangspunkt
Im ersten Teil („Architektur statt Trends: Wie Daten-Ownership die Migration bestimmt“) von Björn Lehnhardt, Managing Director bei Zühlke Deutschland, wird argumentiert, dass die Wahl des Synchronisierungsmusters vor allem von grundlegenden Architekturfragen abhänge – etwa Datenhoheit, Synchronisationsrichtung und Aktualitätsanforderungen.
CDC sei besonders geeignet, um Systeme nahezu in Echtzeit zu entkoppeln und neue Funktionalitäten im Sidecar aufzubauen, ohne das Legacy-System stark zu belasten. Gleichzeitig wird darauf hingewiesen, dass CDC kein Allheilmittel ist, da Initialbefüllung, Monitoring und Konsistenz aktiv adressiert werden müssten. APIs und Batch-Verfahren werden als ergänzende Muster eingeordnet – je nach fachlicher Steuerung oder Latenzanforderung. Von bidirektionaler Synchronisierung wird hingegen abgeraten.
Was ist eine Sidecar-Architektur?
Der Begriff „Sidecar“ geht auf den Beiwagen eines Motorrads zurück. In der IT beschreibt das Pattern eine zusätzliche Komponente, die parallel zu einem bestehenden System betrieben wird – eng angebunden, aber funktional getrennt.
In der Softwarearchitektur wird dabei eine Anwendung („Sidecar“) neben einem Kernsystem platziert, um Funktionen wie Integration, Datenbereitstellung oder neue Services umzusetzen, ohne das Legacy-System direkt zu verändern.
Event-getriebene Integration und wachsende Komplexität
Der zweite Beitrag („Synchronisierungsmuster für Legacy-Systeme: Architektonische Leitplanken für CDC, API und Batch“) von Armin Warda, Chief Technologist bei Red Hat, ordnet die Sidecar-Architektur als taktischen Ansatz ein. Sie könne helfen, neue Funktionen außerhalb des Core-Systems bereitzustellen, erhöhe jedoch langfristig die Systemkomplexität.
Als bewährtes Muster beschreibt Warda eine ereignisgetriebene Integration, bei der minimale Erweiterungen im Core Events erzeugen, die über Middleware wie Kafka verarbeitet werden. Dadurch bleibe die Logik des Legacy-Systems unangetastet und die Kopplung locker. Für Rückkopplungen könnten bestehende Schnittstellen und API-Gateways genutzt werden. Ergänzend empfiehlt er Batch-Jobs, um Datenbestände regelmäßig abzugleichen.
CDC als Default, APIs gezielt einsetzen
Im dritten Teil („Legacy-Synchronisierung: Strategische Muster für eine moderne Banken-Architektur“) von Sven Oldenburg, Direktor Core Banking bei adesso, wird die Sidecar-Architektur als bevorzugter Modernisierungsansatz eingeordnet.
Das Legacy-System bleibe zunächst System of Record, während das Sidecar schrittweise Verantwortung übernehme. Für die Synchronisierung werde CDC in den meisten Fällen als Standard gesehen, da es nahezu in Echtzeit arbeite und das Altsystem nur gering belaste. APIs ermöglichten weiterhin die Nutzung bestehender Fachlogik, führten jedoch zu enger Laufzeitkopplung. Batch-Verfahren eigneten sich vor allem für Reporting und Migration. Insgesamt wird empfohlen, CDC als Basis zu nutzen und APIs gezielt dort einzusetzen, wo fachliche Logik im Kern verbleiben müsse. (td)
