Jede Änderung zieht drei weitere nach sich.
Die Technik ist aktuell, das Team ist gut, und trotzdem wird jedes Feature teurer als das vorige. Wer an einer Stelle etwas ändert, muss an drei anderen nachziehen, weil in Ihrer Software alles mit allem verbunden ist.
Kommt Ihnen das bekannt vor?
Für ein neues Feature müssen sich mehrere Teams abstimmen und warten aufeinander.
Schätzungen stimmen nie, weil erst bei der Umsetzung sichtbar wird, was alles mit dranhängt.
Nur ein oder zwei Personen wissen noch, wie alles zusammenhängt, und ohne sie geht nichts.
Das liegt selten am Alter der Technik. Auch eine Anwendung auf dem neuesten Stand wird zäh, wenn ihre Teile keine klaren Grenzen haben. Am Anfang ist der direkte Zugriff der schnellste Weg: Die Bestellung liest eben kurz in den Kundendaten, die Rechnung greift in die Bestellung. Jede einzelne Abkürzung ist vernünftig, zusammen ergeben sie ein Geflecht, in dem sich kein Teil mehr ändern lässt, ohne andere zu berühren.
KI-Agenten lösen das nicht, sie beschleunigen es. Ein Agent folgt der Struktur, die er vorfindet. Wo Grenzen fehlen, nimmt auch er die Abkürzung, nur viel öfter am Tag als ein Mensch. Sie bekommen mehr Code, aber nicht mehr Auslieferung. Wo ein Modul endet und was es nach außen zeigen darf, ist eine Entscheidung über Ihr Geschäft und nicht über Code. Genau diese Entscheidung lässt sich nicht delegieren.
Was Sie das Abwarten jeden Monat kostet
Diese Kosten wachsen nicht gleichmäßig, sie steigen mit jedem Feature. Was im ersten Jahr eine Woche gedauert hat, dauert im dritten einen Monat, bei gleichem Team. Wer neu ins Team kommt, braucht Monate, bis er sich eine Änderung zutraut. Und fällt die eine Person aus, die das System überblickt, steht die Entwicklung.
Dazu kommt, was Sie nicht bekommen: KI-Werkzeuge, die anderswo spürbar Tempo bringen, helfen bei Ihnen kaum. Jede erzeugte Änderung muss von Hand gegen das ganze System geprüft werden, weil niemand sicher sagen kann, was sie noch berührt.
So gehe ich vor
Abhängigkeiten sichtbar machen
KI-Agenten durchsuchen die gesamte Codebasis und kartieren, welcher Teil auf welchen zugreift, in Tagen statt Wochen. Die Karte bewerte ich mit Ihrem Team: Wo verlaufen die fachlichen Grenzen Ihres Geschäfts, und wo werden sie im Code verletzt? Sie erhalten ein Bild Ihrer Software, das auch ohne technisches Vorwissen verständlich ist.
Grenzen schrittweise ziehen
Ich lege fest, welche Module es gibt und über welche Schnittstellen sie miteinander sprechen. Dann wird Verbindung für Verbindung umgebaut, zuerst dort, wo es Ihr Team am meisten bremst. Die Umbauarbeit übernehmen Agenten nach meinen Vorgaben, ich prüfe jede Änderung. Ihr Produkt bleibt jederzeit lieferfähig.
Regeln absichern
Automatische Architekturtests in der Pipeline lehnen jede Änderung ab, die eine Grenze verletzt, egal ob sie von einem Menschen oder von einem Agenten stammt. Die wichtigsten Entscheidungen sind kurz dokumentiert, damit Ihr Team und seine KI-Werkzeuge wissen, warum die Grenzen dort liegen.
Klassische Architekturaufgaben, die ich übernehme
Dokumentation nach arc42
Kontext, Bausteine, Laufzeit- und Verteilungssicht, dazu Diagramme nach dem C4-Modell. So knapp, dass sie gepflegt wird, und im Repository neben dem Code, damit Ihr Team und seine KI-Agenten sie tatsächlich lesen. Agenten erstellen den ersten Entwurf aus dem Code, ich prüfe und ergänze, was nicht im Code steht.
Architekturentscheidungen festhalten
Architecture Decision Records (ADRs) halten in wenigen Absätzen fest, was entschieden wurde, welche Alternativen es gab und warum sie verworfen wurden. Damit muss in zwei Jahren niemand raten, und auch ein Agent weiß, welche Lösung er nicht vorschlagen soll.
Qualitätsziele und Szenarien
Änderbarkeit, Performance, Sicherheit, Verfügbarkeit: Nicht alles ist gleich wichtig. Ich kläre mit Ihnen, welche Qualitätsmerkmale nach ISO 25010 für Ihr Produkt zählen, und beschreibe sie als prüfbare Szenarien statt als Wunschliste.
Architektur-Review
Ich bewerte eine bestehende oder geplante Architektur gegen diese Qualitätsziele, angelehnt an ATAM. Sie erhalten eine Liste der Risiken, der technischen Schulden und der Kompromisse, nach Wirkung sortiert und mit konkreten Empfehlungen.
Fachlicher Schnitt mit Domain-Driven Design
In Workshops wie Event Storming erarbeite ich mit Ihren Fachleuten, welche Bereiche Ihr Geschäft hat und wie sie zusammenhängen. Daraus entstehen Bounded Contexts und eine Context Map, also die Grenzen, an denen sich später Module und Teams ausrichten.
Schnittstellen und Technologieauswahl
Ich entwerfe Schnittstellen zwischen Modulen und Systemen als geprüfte Verträge, etwa mit OpenAPI, und bewerte Frameworks, Datenbanken und Dienste anhand Ihrer Anforderungen statt anhand von Trends. Jede Empfehlung wird begründet und als Entscheidung dokumentiert.
Häufige Fragen
Müssen wir dafür alles neu schreiben?
Nein. Ein Neubau dauert meist länger als geplant und übernimmt oft dieselben Probleme, weil die Grenzen wieder nicht geklärt sind. Ich baue die bestehende Software schrittweise um, Modul für Modul, während sie weiterläuft.
Brauchen wir dann Microservices?
Meist nicht. Klare Grenzen lassen sich innerhalb einer einzigen Anwendung ziehen, das ist günstiger im Betrieb und für die meisten Teams die bessere Wahl. Eigene Dienste lohnen sich erst, wenn Teile unabhängig voneinander skalieren oder ausgeliefert werden müssen. Wer verknoteten Code auf mehrere Dienste verteilt, hat danach dieselben Knoten und zusätzlich ein Netzwerk dazwischen.
Können wir währenddessen weiter Features entwickeln?
Ja. Der Umbau läuft neben dem Tagesgeschäft. Ich beginne mit den Teilen, an denen Ihre nächsten Features hängen, damit sich die Arbeit sofort auszahlt.
Wann merken wir eine Wirkung?
Die Karte der Abhängigkeiten zeigt meist schon Stellen, die sich schnell lösen lassen. Die erste Grenze ziehe ich dort, wo Ihr Team gerade am meisten Zeit verliert. Sobald sie steht, werden Änderungen in diesem Teil einfacher, lange bevor der gesamte Umbau abgeschlossen ist.
Gilt das nur für das Frontend?
Nein. Kopplung macht an der Grenze zwischen Frontend und Backend nicht halt, oft liegt sie gerade dazwischen: in Schnittstellen, die zu viel verraten, oder in einer Datenbank, auf die alle direkt zugreifen. Ich arbeite auf beiden Seiten, etwa mit TypeScript, Go und Rust.
Kann KI die Architektur nicht einfach selbst entwerfen?
Einen Vorschlag liefert sie in Minuten, und er sieht überzeugend aus. Sie kennt aber weder Ihr Geschäft noch Ihre Teams und weiß nicht, welche Teile sich in zwei Jahren ändern werden und welche nie. Genau davon hängt ab, wo eine Grenze sinnvoll ist. Ich nutze KI, um Abhängigkeiten zu finden und den Umbau umzusetzen. Wo die Grenzen liegen, entscheide ich mit Ihnen und stehe für das Ergebnis ein.
Lassen Sie uns über Ihre Situation sprechen
In einem kostenlosen Erstgespräch schauen wir gemeinsam auf Ihr Problem. Sie erhalten eine ehrliche Einschätzung, ob und wie ich Ihnen helfen kann.
Verwandte Themen
Problem
Ihr Frontend bremst jedes neue Feature aus
Gewachsener Code, veraltete Frameworks und niemand traut sich mehr ran. Ich modernisiere schrittweise, während Ihr Produkt weiterläuft.
Problem
Vor jedem Release klickt jemand alles durch
Tagelange Testrunden, Fehler, die zurückkommen, und Releases, die sich verschieben. Ich automatisiere Ihre Tests, damit Sie öfter und sicherer ausliefern.