Wie komplexe Migrationen in der Finanz-IT gelingen können – ein Erfahrungsbericht aus der Praxis

Monolithische Landschaften prägen viele IT-Architekturen – bis jemand beginnt, sie in modulare Formen zu übersetzen.

Die vollständige Ablösung eines historisch gewachsenen Monolithen gelingt selten auf einen Schlag – das zeigte sich auch in einem groß angelegten Migrationsprogramm bei einer genossenschaftlichen Großbank. Über mehrere Jahre hinweg wurden verschiedene Funktionalitäten schrittweise aus dem Altsystem herausgelöst und durch moderne, modular aufgebaute Individualentwicklungen ersetzt. In einer dieser Phasen wurden drei funktional stark miteinander verzahnte Module parallel in Scrum-Teams entwickelt: für die Veröffentlichung von Produktinformationen, die Emissionssteuerung sowie die interne Workflow- und Aufgabenlogik.

Der Monolith, um den es ging, war über Jahre hinweg erweitert worden – mit zahlreichen impliziten Abhängigkeiten und hoher Änderungsanfälligkeit. Ziel der Migration war es daher, diese Logiken zu entkoppeln, aber gleichzeitig prozessual sauber weiterzuführen. In der Rolle als Product Ownerin war ich für das Modul zur strukturierten Veröffentlichung zuständig – es sollte künftig sicherstellen, dass Produktinformationen automatisiert, standardisiert und revisionssicher an interne und externe Systeme übergeben werden.

Ein zentraler Aspekt war dabei die Dokumentengenerierung: Die Produktdaten mussten so bereitgestellt werden, dass sie im zentralen Dokumententool als valide Quelle für die Erstellung regulatorischer Unterlagen – insbesondere der Endgültigen Bedingungen – genutzt werden konnten. In der Praxis zeigte sich schnell, wie unterschiedlich die Anforderungen aus den Fachbereichen waren – von technischen Schnittstellenthemen bis hin zu juristischen Details. Nicht selten gab es Zielkonflikte oder widersprüchliche Erwartungen, die erst im Dialog greifbar wurden. Ich habe in enger Abstimmung mit den Fachverantwortlichen ein regelbasiertes Vorgehen für die Datenbereitstellung und die Nutzung der Vorlagen aufgesetzt, das wir gemeinsam immer wieder nachgeschärft haben.

Auch die Vorlagenthematik selbst brachte Herausforderungen mit sich: Im Gegensatz zum Altsystem mussten im Zielsystem die passenden Dokumentenvorlagen automatisiert dem jeweiligen Produkt zugeordnet werden – abhängig von zahlreichen fachlichen Merkmalen wie Produktart, Struktur, Basiswert und weiteren Kennzeichen. Diese Logik wurde über umfangreiche Drools-Regeldateien abgebildet, die trotz begrenzter Wartbarkeit bewusst gewählt wurden – als pragmatische Lösung, um Entwicklungsaufwand und Budget zu begrenzen. Gemeinsam mit einem kleinen Kernteam habe ich ein strukturiertes Vorgehen zur Pflege und Versionierung dieser Regeln etabliert sowie eine klare Absicherung bei Fehlerfällen geschaffen – um im gegebenen Rahmen möglichst viel fachliche Transparenz und Testbarkeit sicherzustellen.

Ein zusätzlicher Stolperstein war das Testing. Die verfügbaren Kapazitäten waren sehr begrenzt, und die verantwortliche Testmanagerin noch neu im Thema. Um etwas Struktur reinzubringen, habe ich bei der Planung der Teststrategie mitgeholfen – vor allem, was die spätere Testautomation anging. Zwischendurch habe ich auch immer wieder manuell getestet, einfach um sicherzustellen, dass fachliche Logiken und technische Umsetzungen auch wirklich zueinander passten.

Zusätzlich zur funktionalen Komplexität kam eine organisatorische Herausforderung: Eines der drei Scrum-Teams arbeitete vollständig im Nearshoring-Modell aus Polen. Gerade zu Beginn zeigte sich, wie wichtig klare Kommunikationswege, gemeinsame Refinements und eine transparente Dokumentationsbasis sind, um über Team- und Ländergrenzen hinweg effektiv zusammenzuarbeiten. Viele der Abstimmungen fanden in Workshops und Review-Formaten statt, in denen Schnittstellen, Trigger-Logiken und Prozessverläufe abgestimmt wurden.

Um dem Fachbereich früh greifbare Ergebnisse zu liefern, habe ich klickbare Mockups erstellt, die als Diskussionsgrundlage und Feedback-Trigger dienten. Parallel wurde das Backlog entlang funktionaler MVPs strukturiert, um trotz der technischen Abhängigkeiten eine schrittweise Auslieferung zu ermöglichen.

Das Modul wurde erfolgreich produktiv gesetzt und bildet heute eine tragende Säule in der digitalen Veröffentlichung und Datenbereitstellung strukturierter Produkte. Die vollständige Ablösung des Monolithen wurde im Anschluss weitergeführt – mit einem eingespielten Team, das über Jahre hinweg tiefes fachliches und technisches Know-how in diesem Umfeld aufgebaut hat.

Ein Teil dieses Know-hows ist heute bei twinBAIT zu finden.