// Freiberufliche Softwarearchitektur & Beratung

Durchblick im Microservice-Dickicht.

Ich helfe Unternehmen, mit gewachsenen Microservice-Landschaften wieder handlungsfähig zu werden. Das System darf nicht komplexer sein, als es heute nötig ist und als das aktuelle Team handhaben kann. Wo es darüber hinausgewachsen ist, erarbeiten wir gemeinsam Lösungen: Absicherung durch Tests, Rückbau von Infrastruktur, einheitliche und stabile Umgebungen und Prozesse oder Konsolidierung in einen Modulithen. Ziel ist, möglichst viel zu erhalten, im laufenden Betrieb und ohne Big Bang.

Geringere Kosten
Weniger Komplexität und Fehler
Schnellere Entwicklung neuer Features

Erstgespräch anfragen

// Haltung

Legacy Software erzeugt seit Jahren Geschäftswert, hält Prozesse am laufen. Meine Aufgabe ist es, diesen Wert zu konservieren, statt ihn gegen eine Neuentwicklung einzutauschen.

// Meine Leistungen

Womit ich Sie unterstütze

Bewertung & Zielbild

In zwei bis drei Wochen entsteht ein ehrliches Bild davon, wie Ihr Team tatsächlich arbeitet. Architektur, Code und Kosten gehören dazu, im Mittelpunkt stehen aber die Gespräche: mit Stakeholdern und vor allem mit dem Team selbst. Auf dieser Basis nehmen wir uns gemeinsam Architektur, Code und Vorgehensmodell noch einmal vor und entwickeln ein Zielbild mit priorisierten Handlungsoptionen. Kein Gutachten für die Schublade, sondern eine Entscheidungsgrundlage für Entwicklung und Management.

Rückbau & Konsolidierung

Welcher Weg passt, legt das Zielbild fest. Eine Option ist der Modulith: Fachlich zusammengehörende Services wandern schrittweise zusammen, aus REST-Aufrufen werden Methodenaufrufe, aus verteilten Fehlerbildern lokale Stack-Traces, die fachliche Trennung bleibt als Modulgrenze erhalten. Oft ebenso wirksam ist der Rückbau von Infrastruktur: Jeder Message Broker, Cache und jedes Service Mesh muss seinen Nutzen heute noch belegen. Dazu kommen die Vereinheitlichung und Stabilisierung von Umgebungen und Prozessen, damit Build, Deployment und Betrieb wieder verlässlich laufen und nicht zu viel Zeit fressen.

Absicherung durch Tests

Bei größeren Umbauten sind Tests das Sicherheitsnetz, insbesondere Charakterisierungstests: Sie halten fest, wie sich das System heute tatsächlich verhält. Häufig ist die Entwicklung aber auch im Alltag gelähmt, weil niemand den Blast-Radius einer Änderung abschätzen kann. Dort bringt eine bessere Integrationstestebene beides zurück, Sicherheit und Geschwindigkeit: Die Systemgrenzen sind abgesichert, Testcontainer liefern schnelle Feedback-Zyklen. Abgesichert wird dort, wo als Nächstes geändert wird, nicht flächendeckend als Selbstzweck.

Performance & Stabilität

In gewachsenen Systemen bleiben Engpässe oft unsichtbar, weil Daten fehlen. Deshalb steht am Anfang, Messbarkeit herzustellen: Metriken, Tracing und Logs, die zeigen, wo Zeit und Ressourcen tatsächlich verloren gehen. Auf dieser Grundlage analysiere ich Performance-Probleme, von den Klassikern rund um Hibernate, Datenbanken und Speicher bis zu Sonderfällen wie fehlgeleiteter Authentisierung oder zu klein skalierten HSMs. Lasttests mit Gatling, JMeter oder k6 gibt es gezielt für die kritischen Bereiche, so gebaut, dass sie dauerhaft in der Pipeline nutzbar bleiben.

Trusted Advisor

Bei Bedarf regelmäßig als Sparringspartner für Entscheider: Zweitmeinung zu Architektur- und Investitionsentscheidungen, Reviews zentraler Designs, Vorbereitung von Lenkungsausschüssen und Übersetzung zwischen Entwicklung und Management. Verlässlich erreichbar, ohne permanent im Projekt zu sitzen.

Coaching am Code

Wissenstransfer entsteht am gemeinsamen Code, nicht im Foliensatz: Pairing, Mob Programming, Code Reviews, Architektur-Workshops und Arbeit an der konkreten Codebasis. Dazu gehört auch, Agentic Coding sinnvoll einzusetzen, etwa für Charakterisierungstests und die Vereinheitlichung gewachsener Strukturen. Ziel ist ein Team, das den Weg eigenständig fortsetzt.

Wie eine Zusammenarbeit anfängt, wie lange sie dauert und was sie kostet: häufige Fragen.

// Aus der Praxis · Infrastruktur

Weniger Infrastruktur für ein kleineres Team

Es wurde klar, dass nicht Tausende Nutzer gleichzeitig mit dem System arbeiten werden. Es wurden weniger Features benötigt, das Team wurde kleiner, die Landschaft aber nicht. Also haben wir die Caching-Infrastruktur abgebaut und die Datenhaltung auf ein einziges DBMS reduziert. Ergebnis: zwei Drittel weniger Terraform, einfacherer Code in der Anwendung und ein System, das auch das kleinere Team stabil betreiben kann.

// Aus der Praxis · Tests

Tests, denen das Team vertraut

Ohne verlässliche Tests war jede Änderung ein Risiko, und das Team arbeitete entsprechend vorsichtig und für Außenstehende zu langsam. Wir haben eine ausgewogene Testsuite aufgebaut: von beschreibenden Unit-Tests, die zeigen, was der Code tun soll, bis zu Integrationstests, die das Verhalten des Systems absichern. Ergebnis: ein Team, das seinen Tests vertraut und Änderungen deshalb mit Sicherheit und ausgewogenem Tempo angeht.

Mein Artikel zum Thema auf Entwickler.de

// Aus der Praxis · Monitoring

Wissen, warum das System langsam ist

Die Basis ist immer zu wissen, warum ein System langsam ist: Liegt es an der eigenen Anwendung oder an einem Upstream-System? Ohne diese Antwort kamen Störungen erst über Eskalationen beim Team an. Mit gezielt aufgebautem Monitoring ist die Ursache jetzt sichtbar, und das Team kann selbst eskalieren, bevor es andere tun. Das hat das Vertrauen auf Kundenseite deutlich verbessert.

// FAQ

Häufige Fragen

Die Fragen, die in Erstgesprächen am häufigsten kommen.

Woran erkenne ich, dass mein System betroffen ist?

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.

Wie fängt eine Zusammenarbeit an?

Mit einer Bewertung des Ist-Zustands über zwei bis drei Wochen. Der Fokus liegt darauf, wie das Team tatsächlich arbeitet. Neben Architektur, Code und Kosten gehören dazu Gespräche mit Stakeholdern und vor allem mit dem Team selbst. Auf dieser Basis setzen wir uns noch einmal mit Architektur, Code und Vorgehensmodell auseinander. 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.

Muss der Betrieb dafür angehalten werden?

Nein. Der Umbau läuft in Schritten, die einzeln produktiv gehen und einzeln zurückgenommen werden können. Welche Schritte im laufenden Betrieb möglich sind, welche ein Wartungsfenster brauchen und was parallel laufen kann, klärt das Zielbild vorab.

Wir haben kaum Tests. Ist das ein Ausschlusskriterium?

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.

Was kostet das?

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.

Alle Fragen →

// Nächster Schritt

Lohnt sich der genauere Blick auf Ihr System?

Ein Erstgespräch ist unverbindlich. Wenn Sie mögen, schauen wir gemeinsam auf Ihre Landschaft und klären, wo der größte Hebel liegt.

Erstgespräch anfragen