Ich war mehrere Jahre in einem großen Versicherungsprojekt unterwegs – bei der Entwicklung eines Bestandssystems. Java-Monolith, organisch gewachsen, mehrere Jahrzehnte Fachlichkeit im Gepäck.
Der Auftrag, mit dem ich in das Projekt kam: Entwicklungscoaching, Codequalität verbessern, Testbarkeit erhöhen.
Was ich vorgefunden habe, war allerdings ein System, in dem nicht primär ‚schlechter Code‘ das Problem war, sondern eine Meta-Architektur, die Produktivität und Testbarkeit systematisch ausgebremst hat.
Durchdacht und trotzdem problematisch
Die zentrale Anwendung erzeugt für unterschiedliche Sparten Versicherungsscheine – mit komplexen Produkten, Varianten und vielen Besonderheiten, wie sie in der Versicherungsbranche üblich sind.
Das System war ein klassischer Enterprise-Monolith auf Java-Basis mit einem eigenentwickelten Architekturvorgehen.
Auf dem Papier sah vieles vernünftig aus:
- klare Architekturprinzipien
- konsequente Abstraktion für klare Klassensignaturen
- eine Trennung von technischer Plattform und fachlicher Logik
- Fachbereich als direkter Bestandteil des Teams
- enge Zusammenarbeit verschiedener Disziplinen
- spezifische Initiativen zur Verbesserung der Qualität
In der Realität zeigten sich jedoch immer wieder dysfunktionale Symptome:
- Features dauerten lange und benötigten zahlreiche Revisionen
- Tickets wurden begonnen und blieben stecken
- es wurde mehr gestartet als beendet
- technologische Updates mit neuen Möglichkeiten standen an – wurden aber nur zögerlich genutzt
Das Myzel der Ursachen
In historisch gewachsenen Systemen und Teams ist es selten möglich, ‚den einen‘ Auslöser für die Probleme zu benennen. So war es auch hier: Die augenscheinlichen Probleme waren Symptome eines tiefer liegenden Geflechts aus technischen und organisatorischen Entscheidungen.
Die technische Herausforderung
Am Anfang wirkt ein firmeneigenes Architekturvorgehen oft beeindruckend: Schaubilder, Schichtenmodelle, sprechende Bausteine, einheitliche Regeln. Als ich die Architektur-Dokumentation kennengelernt habe, war mein Eindruck zunächst: „Ambitioniert, aber nicht völlig abwegig. Wenn man das konsequent durchzieht, kann man damit arbeiten."
Genau hier lag das Problem: Es wurde nicht konsequent durchgezogen.
Im Laufe der Umsetzung stellte man fest, dass bestimmte Konzepte der Architektur zu Performanceproblemen führten – und setzte sie deshalb nicht wie vorgesehen um. Was wie Pragmatismus wirkte, führte in diesem Fall zu einem Verlust an Integrität: Im Architekturvorgehen entstand ein Vakuum, und die Stabilität des Gesamtkonzepts begann zu wanken.
Die Sache mit der Abstraktion
Basis der konkreten Umsetzung im Projekt war die Modellierung von Klassen in UML. Aus dem Modell wurde über einen Generator abstrakte Java Klassen generiert, die anschließend ausimplementiert werden mussten. Wenn sich etwas an der Signatur einer Klasse änderte, musste das Modell angepasst und neu generiert werden – mit Auswirkungen auf das gesamte Team.
Parallel dazu gab es eine separate Umgebung für die Businesslogik in einer eigens dafür entwickelten Sprache – mit eigenem Repository, eigenen Werkzeugen und eigener Release-Logik.
Die Java-Klassen waren nicht nur abstrakt, sondern zusätzlich sehr generisch, mit definierten Übergabepunkten an die Businesslogik-Engine.
Das hatte mehrere Konsequenzen:
- Für eine Änderung mussten in der Praxis alle drei Repositories (Code, Businesslogik, UML-Modell) gebrancht und später wieder gemergt werden – oder man entwickelte riskant direkt auf dem Main-Branch.
- Schon kleine Anpassungen zogen sich durch Modell, generierten Code und DSL – inklusive der jeweils eigenen Tooling- und Freigabeprozesse.
Die Testbarkeit geriet dabei schnell ins Hintertreffen.
Es gab kaum natürliche ‚Cut here‘-Punkte, an denen sich Methoden oder fachliche Verantwortlichkeiten sinnvoll extrahieren ließen. Unit-Tests im klassischen Sinne – kleine, schnelle Tests für klar umrissene Verantwortlichkeiten – waren damit kaum realistisch.
Die Folge war eine Teststrategie, die vor allem auf großen, schwergewichtigen Tests beruhte:
- Integrationsszenarien
- End-to-End-Flows
- viel Setup, umfangreiche Testdaten
Dass Teile des Teams irgendwann sagten: „Tests sind bei uns halt aufwendig“, war nachvollziehbar – das System war schlicht nicht darauf ausgelegt, gut testbar zu sein.
Parallel dazu verstärkten organisatorische Strukturen die technische Komplexität:
- dedizierte Datenbank-Teams, die jede Änderung an Indizes und Strukturen freigeben mussten
- separate UI-Einheiten mit eigenen Prioritäten, während im Projekt gleichzeitig generische Oberflächenkomponenten genutzt wurden
In Summe ergab sich eine Architektur, die nicht nur komplex war, sondern: komplex auf eine Weise, die jede Verbesserung doppelt teuer machte.
Architektur ist Haltung: Wo technische und organisatorische Überzeugungen aufeinandertreffen
Architektur ist nie nur Technik – sie ist immer auch Ausdruck von Haltungen und Prioritäten. In komplexen Organisationen gibt es oft sehr unterschiedliche Vorstellungen davon, was ‚gute Architektur‘ bedeutet und wo der Fokus liegen sollte.
In diesem Projekt kristallisierte sich eine Sichtweise heraus, die maßgeblichen Einfluss hatte:
- technische Qualität wurde gegenüber der fachlichen Spezifikation als nachrangig betrachtet
- lange, kommentierte Methoden wurden bevorzugt gegenüber kleinen, fokussierten Einheiten
- Konsistenz und Lesbarkeit wurden als Detailfragen verstanden
Diese Haltung hatte direkte Konsequenzen.
Maßnahmen wie SonarQube oder Code-Reviews konnten lokale Verbesserungen bewirken. Solange die grundlegende Architekturhaltung jedoch davon ausging, dass technische Aspekte zweitrangig seien, blieben strukturelle Probleme bestehen:
- Überladene Domänenobjekte erschwerten klare Verantwort
- Testen blieb an vielen Stellen ein Großprojekt statt eines selbstverständlichen Schritts im Entwicklungsprozess lichkeiten
- fehlende Schnittstellen verhinderten sinnvolle Unit-Tests
Die Grenzen des Coachings
Trotz der strukturellen Herausforderungen gab es im Projekt viele engagierte Menschen. Ein Teil des Auftrags bestand darin, diese Energie aufzunehmen und in konkrete Maßnahmen zu übersetzen.
Es wurden sichtbare Anker für Qualität gesetzt:
SonarQube und Qualitäts-Dashboard:
Metriken wurden erhoben, Flaws sichtbar gemacht, erstmals entstand ein objektiver Überblick über die Qualitätsentwicklung im Zeitverlauf.
Wöchentliche Quality Sessions:
Wöchentlich gab es Raum für Refactorings, Code-Analysen und das gezielte Abbauen technischer Schulden. Besonders jüngere Kolleg:innen nutzten diesen Rahmen aktiv.
Coaching zu technischen Neuerungen:
In langlaufenden Projekten stehen oft Updates der verwendeten Programmiersprachen und Bibliotheken an. Neue Möglichkeiten sinnvoll zu nutzen, war ein wichtiger Schwerpunkt.
Testvorgehen und Testpyramide:
Moderne Teststrategien wurden vermittelt und diskutiert. In der Praxis prallten sie jedoch immer wieder an der Architektur ab – schlicht, weil passende Schnittstellen fehlten.
Diese Maßnahmen zeigten Wirkung: positives Feedback, spürbare Lernkurven, erste sichtbar bessere Code-Bereiche.
Gleichzeitig blieb deutlich:
Solange die grundlegende Architektur- und Organisationsstruktur unverändert blieb, hatten diese Initiativen ein natürliches Wirkungslimit. Coaching kann Mikromaßnahmen stärken – Makroprobleme in Architektur und Organisation lassen sich dadurch allein jedoch nicht lösen.
Was ein Architekturreview hier leisten kann
Ein externes Architekturreview schafft einen geschützten Rahmen in dem technische und organisatorische Probleme klar benannt, Qualitätskriterien definiert und Handlungsmaßnahmen entwickelt werden können. Ein gutes Architekturreview liefert nicht einfach ein „Ja“ oder „Nein“ zur Architektur, sondern eine strukturierte Entscheidungsgrundlage:
- Eine Risiko-Heatmap, die zeigt, wo sich Produktivität, Wartbarkeit und Go-Live-Risiken ballen – und welche davon auf Architektur- statt auf Team-Ebene entstehen.
- Einen priorisierten Maßnahmenkatalog:
- kurzfristig: konkrete Refactoring-Zonen für bessere Testbarkeit
- mittelfristig: Reduktion von Eigenframeworks und Vereinfachung der Schichten
- langfristig: ein möglicher Pfad hin zu modularerer Struktur.
- Management-Szenarien mit ehrlichen Kosten-Nutzen-Betrachtungen:
- ‚Weiter wie bisher‘ mit erwartbaren Auswirkungen auf Geschwindigkeit und Kosten
- ‚Gezielte Investition‘ in die Entschärfung kritischer Architekturpunkte
- optional ein ‚radikaler Neuschnitt‘ bestimmter Teile – inklusive grober Kosten-/Nutzen-Abschätzung
Im Rahmen des Projektes war es leider nicht möglich, das umzusetzen. Ideal wäre ein Review gewesen, als sich die Symptome verdichtet hatten:
- lange Ticketlaufzeiten
- aufwendige Bugfixes
- wahrnehmbare Schwierigkeiten bei Testbarkeit und Wartbarkeit
Zu diesem Zeitpunkt war das System zwar groß, aber noch nicht an einem Punkt, an dem jede Änderung als existenzielle Bedrohung empfunden wurde.
Die möglichen Erkenntnisse
Ein strukturiertes Architekturreview hätte die wichtigsten Problemfelder klar herausgearbeitet:
Meta-Architektur als Produktivitätskiller
Die Kopplung von UML-Modell, generiertem Code und externer Businesslogik-DSL sorgte für eine künstliche Vervielfachung des Aufwands pro Änderung.
Empfehlung: Reduktion der Mappingschichten, klare Verantwortlichkeiten pro Ebene, wo möglich Zusammenführung oder Eliminierung redundanter Stränge.
Eigenframework als Komplexitätsfalle
Abstraktionsschichten um etablierte Frameworks reduzierten nicht die Komplexität, sondern verschoben sie – und erschwerten Debugging, Testbarkeit und Weiterentwicklung.
Empfehlung: Kritische Analyse des Mehrwerts, Rückbau zugunsten der direkten Nutzung von Standardframeworks, Übergangsstrategie zur Befähigung der Teams.
Überladene Domänenobjekte und fehlende Schnittstellen für Tests
Zentrale Klassen bündelten Datenhaltung, Steuerlogik und Fachentscheidungen, wodurch sinnvolle Unit-Tests praktisch unmöglich wurden.
Empfehlung: Identifikation fachlich kohärenter Verantwortlichkeiten, Auftrennen in testbare Einheiten, Definition klarer Schnittstellen.
Inkonsistente Architekturprinzipien
Ein zentrales Pattern wurde aus Performancegründen entfernt, ohne das Gesamtdesign anzupassen – Dokumentation und Implementierung liefen auseinander, Entscheidungen wurden situativ.
Empfehlung: Klar benennen, wo Soll- und Ist-Bild nicht mehr übereinstimmen, und dann eine explizite Entscheidung erzwingen: konsequente Umsetzung oder Anpassung des Zielbilds.
Soziotechnische Risiken
Architekturentscheidungen waren eng an Rollen und Personen gebunden, deren Status davon abhing, dass „die Architektur trägt“. Kritische Rückmeldungen wurden politisch gefiltert.
Empfehlung: Transparente Risikodarstellung in Management-tauglicher Form, klare Trennung zwischen fachlicher Analyse und politischer Entscheidung.
Die Stärke externer Perspektiven
In diesem Projekt fehlte dieser Schritt. Es gab viele gute Bausteine: engagierte Menschen, Metriken, Qualitätsrunden. Ohne ein klar gerahmtes, extern moderiertes Architekturreview blieben die wirklich unangenehmen Erkenntnisse jedoch entweder im Team stecken – oder wurden auf dem Weg nach oben weichgezeichnet.
Die Stärke eines formalen Architekturreviews liegt genau hier:
- Es schafft einen Rahmen, in dem technische und organisatorische Probleme klar benannt werden dürfen.
- Es übersetzt diese Erkenntnisse in eine Form, mit der ein Management konstruktiv arbeiten kann – nicht als Schuldzuweisung, sondern als Grundlage für informierte Entscheidungen.
Clean Code, Coaching und Qualitätsinitiativen sind wertvoll und notwendig. Wenn die Architektur selbst jedoch systematisch gegen Produktivität und Wartbarkeit arbeitet, braucht es zusätzliche Werkzeuge – und die Bereitschaft, auch strukturelle Wahrheiten auszusprechen.
