FAQ

Mit einer Bewertung des Ist-Zustands, je nach Größe des Systems drei bis zehn Tage. Dazu gehören eine Code- und Architekturanalyse, ein Blick auf Infrastruktur und Betriebskosten sowie Gespräche mit Entwicklung, Architektur, Betrieb und Stakeholdern. Am Ende steht ein ehrliches Bild plus ein Zielbild mit priorisierten Handlungsempfehlungen, Aufwandsschätzungen und erwartetem Einsparungspotenzial.

Das ist bewusst ein Einstieg ohne großes Commitment. Ob danach ein längeres Mandat folgt, entscheiden Sie mit dem Ergebnis in der Hand.

Drei, je nach Rolle:

• Bewertung und Zielbild (3 bis 10 Tage) als Einstieg.
• Trusted-Advisor-Mandat (laufend, 1 bis 4 Tage pro Monat): Sparring zu Architektur- und Investitionsentscheidungen, Reviews, Zweitmeinungen, Vorbereitung von Lenkungsausschüssen.
• Absicherung, Rückbau und Konsolidierung (3 bis 12 Monate): das operative Mandat mit Pairing, Workshops, Architekturarbeit und Mitarbeit am Code.

Die Formate lassen sich kombinieren. Häufig folgt auf ein operatives Mandat ein kleineres Advisor-Mandat, damit das Team den Weg eigenständig weitergeht und trotzdem jemanden zum Gegenlesen hat.

Die Abrechnung läuft nach Aufwand auf Basis eines Tagessatzes, den ich Ihnen gerne im Gespräch nenne. Für die Bewertung lässt sich der Aufwand vorab eingrenzen, weil Umfang und Dauer feststehen.

Für die Entscheidung ist die andere Seite der Rechnung wichtiger: Was kosten heute die Infrastruktur, die Bereitschaft und die Kapazität, die im Verwalten gebunden ist? Genau dafür liefert die Bewertung Zahlen.

Typische Anzeichen, meist fünf bis acht Jahre nach der ursprünglichen Microservice-Entscheidung:

• Ein Team betreut drei oder fünf Services, weil es die anderen Teams nicht mehr gibt.
• Services laufen dauerhaft bei einstelliger Auslastung, unabhängige Skalierung war nie nötig.
• Mehrere Services müssen in fester Reihenfolge deployed werden, sonst geht nichts.
• Die Fehlersuche zieht sich über mehrere Systeme und dauert Tage statt Stunden.
• Die Betriebskosten steigen, der fachliche Nutzen bleibt gleich.

Wenn Sie zwei oder drei Punkte wiedererkennen, lohnt der genauere Blick.

Weil im bestehenden System hunderte Sonderfälle, Workarounds und fachliche Regeln stecken, die nirgends dokumentiert sind. Das ist kondensierte Geschäftslogik, die sich über Jahre unter realen Bedingungen bewährt hat.

Wer neu anfängt, muss all das erneut entdecken. In der Zwischenzeit läuft das alte System weiter und wird weiter gepflegt. Nach drei Jahren steht dann oft ein zweites Legacy-System, mit weniger fachlichem Wissen als das erste.

Er ist die Antwort auf die heutige Last und die heutige Team-Größe. Die fachliche Trennung bleibt erhalten, sie wird nur anders durchgesetzt: Was vorher Service-Grenze war, wird Modulgrenze, technisch abgesichert über Spring Modulith, Paketstrukturen oder ArchUnit.

Weg fällt der technische Aufwand drumherum: Netzwerkaufrufe zwischen Komponenten, die immer zusammen deployed werden, mehrere Datenbanken mit Synchronisation, verteilte Fehlerbilder.

Wenn es einen belegbaren Grund gibt: unabhängige Skalierung um ein Vielfaches, organisatorische Unabhängigkeit mehrerer Teams, die tatsächlich parallel arbeiten, oder regulatorische Trennung.

Liegt einer dieser Gründe vor, bleibt der Schnitt. Der Rückbau richtet sich nicht gegen verteilte Systeme, sondern gegen Verteilung ohne Begründung.

Im Gegenteil, das ist der Normalfall und der Grund für die dritte Phase. Charakterisierungstests halten fest, wie sich das System heute tatsächlich verhält, inklusive der Eigenheiten aus Jahren im Betrieb. Dazu kommen Integrationstests an den Systemgrenzen und eine Testinfrastruktur mit kurzen Feedback-Zyklen.

Abgesichert wird zuerst, was als Nächstes geändert wird. Flächendeckende Testabdeckung als Selbstzweck kostet Monate und bringt für den Umbau wenig.

Eine praktische. Coding-Agenten erschließen bestehenden Code systematisch und liefern Entwürfe für Charakterisierungstests. Sie können außerdem ein einmal definiertes Zielmuster über hunderte Klassen anwenden, etwa beim Abschluss halbfertiger Refactorings.

Die Architekturentscheidung bleibt beim Menschen. Und je einheitlicher die Codebasis ist, desto verlässlicher arbeiten die Agenten: Auf einer inkonsistenten Codebasis produzieren sie inkonsistente Ergebnisse.

Der Schwerpunkt liegt auf der JVM: Java, Spring Boot, Spring Modulith, Hibernate, Gradle und Maven, dazu ArchUnit und Testcontainers für Architektur- und Testabsicherung sowie Gatling, JMeter oder k6 für Lasttests. Im Frontend habe ich mit Vue.js, React und Angular gearbeitet.

Die Architekturarbeit selbst ist nicht an einen Stack gebunden. In verteilten Landschaften gehören Message Broker, Caches, Datenbanken, CI/CD und Monitoring ohnehin zum Bild.

Ich komme nicht mit einem Foliensatz, sondern arbeite am Code mit. Die Muster, um die es geht, kenne ich aus eigener Praxis: das Service Mesh, das niemand mehr durchdringt, das Event, das nie ein zweiter Konsument liest, der Cache, der einen fehlenden Index kaschiert.

Dazu kommt die Übersetzung in beide Richtungen. Einem Team erkläre ich nicht, warum Tests wichtig sind, ich schreibe sie gemeinsam mit ihnen. Dem Management erkläre ich nicht abstrakt den Wert von Refactoring, sondern was es konkret kostet, es nicht zu tun: längere Feature-Zyklen, höhere Fehlerquoten, steigende Wartungskosten.

Die Metapher kommt aus der Stadtplanung. Eine Industriebrache wird nicht abgerissen und neu gebaut, sondern Schritt für Schritt in einen Ort verwandelt, an dem man gut arbeiten kann. Die Substanz ist da, sie muss freigelegt, gesichert und gepflegt werden.

Genauso arbeite ich an gewachsener Software: erkennen, was trägt, gezielt entfernen, was im Weg steht, und dafür sorgen, dass das Ergebnis gepflegt weiterlebt.