Das erläutern Michael Bock, IT-Leiter bei MLF Mercator-Leasing, und Mario Herb, Principal Software Architect bei Gofore, in einem aktuellen Gastbeitrag im IT Finanzmagazin. Leasco bündelt bislang zentrale fachliche Domänen des Leasinggeschäfts – von Geschäftspartner-Stammdaten und Bonitätsprüfung über die Vertragsverwaltung bis zu Finanzbuchhaltung und Refinanzierung.
Schrittweise Entkopplung statt Big Bang
Mercator-Leasing verfolgt bei der Ablösung keine Komplettmigration. Einzelne fachliche Bereiche werden sukzessive aus dem Altsystem herausgelöst. Bei der Geschäftspartnerverwaltung liege die Schreibhoheit inzwischen im neuen Java-Kern. Da Leasco keine entsprechenden APIs bereitstelle, würden die Daten über eine abgesicherte Schnittstelle weiterhin synchron an das Altsystem übertragen.
Auch die Bonitätsprüfung wurde nach Angaben der Autoren neu aufgebaut und um regelbasierte Anbindungen externer Auskunfteien ergänzt. Beim Vertragskern sei der produktive Einstieg über das datenintensive Benefit-Geschäft erfolgt, zu dem unter anderem Bike-Leasing gehört. Parallel würden SAP für die Finanzbuchhaltung und BearingPoint Assets & Finance für die Refinanzierung angebunden.
Eine Case Study von Gofore ordnet das Vorhaben zusätzlich ein. Demnach war die technologische Basis der bisherigen Vertragsverwaltung seit mehr als 30 Jahren im Einsatz. Als Herausforderung wird dort unter anderem beschrieben, dass detailliertes Wissen über das Altsystem auf wenige Personen konzentriert gewesen sei.
Warum kein Microservices-Ansatz?
Bei der Zielarchitektur entschied sich Mercator-Leasing bewusst gegen Microservices und für einen modularen Monolithen. Die neue Anwendung basiert auf Java, Spring Boot, hexagonaler Architektur und Domain-Driven Design und wird auf AWS in der Region Frankfurt betrieben.
Bock und Herb zufolge können fachliche Transaktionen innerhalb der jeweiligen Modulgrenzen lokal und ACID-konsistent bleiben. Damit lasse sich zusätzliche Komplexität vermeiden, die bei verteilten Microservices etwa durch verteilte Transaktionen oder Saga-Mechanismen entstehen könne. Über externe Systemgrenzen hinweg – beispielsweise zu SAP und BearingPoint Assets & Finance – setzt Mercator-Leasing dagegen auf asynchrone Verarbeitung und definierte Abgleichverfahren.
Die Entscheidung gegen Microservices ist dabei nicht grundsätzlich. Durch die Isolation der einzelnen Domänen sollen diese bei Bedarf später als eigenständige Microservices herausgelöst werden können, etwa wenn eine unabhängige Skalierung oder eine stärkere Trennung von Entwicklungsteams erforderlich wird.
Mehr als 600.000 aktive Verträge
Welche Anforderungen die neue Architektur bewältigen muss, zeigt die Sollstellung von mehr als 600.000 aktiven Verträgen. Nur fachlich vollständige Vorgänge sollen in die Verbuchung gelangen; die Übertragung an die Finanzbuchhaltung erfolgt asynchron.
Auch für weitere Aufgaben wurden spezifische Verfahren aufgebaut. Ein Operational Data Warehouse soll synchrone Abfragen im Tagesgeschäft reduzieren. Bei der Dokumentenarchivierung werden Dateien direkt in einem Objektspeicher abgelegt und über Referenzen innerhalb der Messaging-Infrastruktur verarbeitet. Die unveränderbare Ablage erfolgt anschließend im ELO-Archiv.
Die Cloud-Infrastruktur wird nach Angaben der Autoren über Infrastructure as Code mit OpenTofu verwaltet. Neue Entwicklungs- und Testumgebungen könnten dadurch automatisiert bereitgestellt werden.
Die Herausforderung liegt nicht nur im COBOL-Code
Als eine zentrale Erfahrung aus dem Projekt beschreiben Bock und Herb die organisatorische Dimension der Modernisierung. Die Komplexität habe weniger im Code als in der Organisation gelegen. Mit der Herauslösung einzelner Bounded Contexts hätten sich etablierte Prozesse, Verantwortlichkeiten und Schnittstellen verändert. Auch Führungsebenen hätten deshalb kontinuierlich in die Transformation eingebunden werden müssen.
Parallel dazu müsse Mercator-Leasing eigenes Know-how für Betrieb und Weiterentwicklung der cloudnativen Plattform aufbauen. Eine solche Zielarchitektur lasse sich nach Einschätzung der Autoren nicht dauerhaft vollständig auslagern.
Die Transformation ist noch nicht abgeschlossen. Das Ziel bleibe, weitere fachliche Bereiche schrittweise aus Leasco herauszulösen und das COBOL-Altsystem schließlich vollständig zurückzubauen.
Der Ansatz von Mercator-Leasing zeigt dabei eine Alternative zu einer häufig diskutierten Modernisierungslinie: Auf den gewachsenen COBOL-Monolithen folgt nicht zwangsläufig eine verteilte Microservices-Landschaft, sondern zunächst ein fachlich modularisierter Java-Monolith. (td)
