Seit 2019 sind wir bei einem großen deutschen Unternehmen im Einsatz. Was ursprünglich als zeitlich begrenztes Projekt begann, hat sich mittlerweile zu einem langfristigen Modernisierungsprogramm entwickelt. Ziel ist es, den Sprung von alten Host-Anwendungen (PL/I) in eine moderne, serviceorientierte Architektur zu schaffen.
Ausgangslage: ein Anbieter zwischen den Jahrzehnten
Die Altanwendung, die wir ablösen sollten, stammt aus den 80er- und 90er-Jahren und wurde über Jahrzehnte angepasst und erweitert. Heute hängt sie noch an einem Java-Swing-basierten Rahmen, der über eine Browser-Integration bereitgestellt wird.
Die Aufgabe
- Verträge, Dokumente und Zusatzpakete sollen künftig über das neue System abgerechnet und bearbeitet werden können
- Dafür brauchte es eine neue Anwendung für interne Sachbearbeiter, die die alte PL/I-Lösung vollständig ersetzt.
- Langfristiges Ziel: Schritt für Schritt die Host-Anteile abschalten und den Weg für eine moderne Webarchitektur frei machen.
In der Zukunft soll auch das Swing-Framework endgültig verschwinden und durch ein reines Web-Frontend ersetzt werden.
Architektur: Säulen, Services und Standardisierung
Das Unternehmen setzt auf eine selbst entwickelte Architektur, die alle Projekte bündelt. Sie besteht aus sogenannten Säulen, die jeweils fachlich abgegrenzte Domänen abbilden, in diesem Fall rund um Vertrags- und Abrechnungsprozesse.
Technisch sieht das so aus:
- Pro Säule eine Spring-Boot-Anwendung, die über REST-APIs erreichbar ist.
- Frontend-Anbindung über Angular, mit einheitlichen Core Components (z. B. Tabellen, Date-Picker, Formularlogik), damit Nutzer sich in allen Anwendungen zurechtfinden.
- Globale Basiskonfiguration: Versionsmanagement (z. B. Spring-Versionen) wird von einer zentralen Architektur-Gilde koordiniert.
- Kommunikation zwischen Säulen erfolgt ebenfalls über REST, teils ergänzt durch SOAP-Anbindungen zu externen Diensten (z. B. Validierung von Vertrags- oder Kundendaten).
- Zentrale Schlüssel-Säule, die Stammdaten konsistent über mehrere Schnittstellen bereitstellt.
- Input-Management via Message-Queues für Eingangsdaten, etwa wenn Vertragsänderungen per App oder Briefe durch den Scanprozess eingehen.
Im Backend setzen wir auf Java, Spring Boot, JPA, Camunda, im Frontend auf Angular. Für die Testumgebungen nutzen wir Docker und Testcontainers, Datenbankzugriffe laufen aktuell auf DB2, wenngleich PostgreSQL im Nachhinein die bessere Wahl gewesen wäre.
Die größten Stolpersteine
1. Camunda und die UI-Sperren
Camunda war ein Wunsch des Kunden, welcher schon länger bestand, aber relativ kurzfristig in eine Business Process Engine integriert werden sollte, noch vor dem ersten Release. Das brachte Probleme:
- Synchronisation mit dem interaktiven Frontend: Sobald im Hintergrund ein Prozess weiterläuft, ohne dass ein User-Task ansteht, kann das Frontend keine konsistenten Daten anzeigen.
- Lösung war, das UI in diesen Phasen zu sperren – mit dem Nebeneffekt, dass bei Fehlern auch die gesamte Oberfläche blockiert blieb. Das führte zu Problemen in der Anwendung.
2. One Page – One Request (oder besser nicht)
Die Idee war anfangs charmant: jede Seite lädt sich mit einem Request komplett neu. In der Realität wuchsen die Datenmengen und Abhängigkeiten so stark, dass Ladezeiten explodierten. Wir haben das Konzept später aufgegeben und auf feinere Nachlade-Strategien umgestellt.
3. Datenbankstrategie
Der Kunde bestand auf einem manuellen DB-Release-Verfahren anstelle von Flyway, da es in der Organisation seit Jahren so praktiziert wird. Das bedeutet, dass Skripte doppelt gepflegt werden müssen – einmal für Flyway und einmal für das manuelle Verfahren. Gerade in Testumgebungen ist das ein echter Produktivitätskiller.
Dazu kam die Entscheidung für DB2, getrieben durch das Know-how einzelner Experten im Haus. Rückblickend wäre PostgreSQL die nachhaltigere Wahl gewesen, da ein Teil der internen Experten des Kunden im Laufe des Projektes in Rente ging oder die Firma verließ. Ein weiterer wichtiger Punkt ist, dass sich der gesamte Markt insgesamt mehr zu Postgres hin entwickelt.
Lessons Learned – was ich heute anders machen würde
- Frühe Einbindung von Endanwendern: Mehr User-Workshops hätten uns geholfen, unnötige Features zu vermeiden und echte Pain Points besser zu verstehen.
- Camunda von Anfang an einplanen: Späte Integration einer Process Engine verursacht Mehraufwand und bricht bestehende Usecases unnötig auf.
- Flyway konsequent einsetzen: Ein einheitliches Verfahren für alle Umgebungen spart langfristig deutlich mehr Zeit als die Pflege paralleler Prozesse.
- Technologieentscheidungen mit Weitblick: Personelle Engpässe können ein Projekt in eine ungewollte Abhängigkeit treiben – DB2 vs. PostgreSQL war dafür ein Paradebeispiel.
Ergebnisse: Go-Live und Roadmap
- Anfang 2024: Release 1.0, erste Dokumententypen gingen produktiv, der Go-Live verlief reibungslos.
- Mitte 2024 und 2025: Release 2.0 und 3.0 erweitern den Funktionsumfang deutlich; Userfeedback wurde integriert.
- Zukünftig: Schrittweise vollständige Migration aller Dokumententypen und Ablösung von Swing.
Fazit
Das Projekt zeigt sehr deutlich, wie schwierig, aber auch wie lohnenswert die Modernisierung gewachsener Systemlandschaften ist. Alte Host-Anwendungen durch moderne Spring-Boot-Services und Angular-Frontends zu ersetzen, ist kein Sprint, sondern ein Marathon mit vielen Stolpersteinen.
Aber: Der Kunde hat heute eine stabile, erweiterbare Architektur, die langfristig tragfähig ist. Und wir haben wieder einmal gelernt, wie entscheidend die Kombination aus technischer Exzellenz und organisatorischem Change ist.
