Architekturentscheidungen wirken im Moment der Umsetzung oft sauber und logisch. Das System funktioniert, die Anforderungen sind erfüllt und die Lösung fühlt sich stabil an. Die eigentlichen Kosten entstehen jedoch nicht beim Bauen, sondern beim Verändern.
Genau dort zeigt sich, wie gut oder schlecht eine Architektur wirklich ist.
1. Was wir optimieren und was wir dabei übersehen
In der Praxis werden Architekturentscheidungen häufig unter lokalen Zielen getroffen:
- Schnelle Feature-Umsetzung
- Klare Trennung einzelner Module
- Saubere Struktur im aktuellen Scope
Diese Ziele sind sinnvoll, aber sie betrachten selten den zeitlichen Faktor: wie sich das System unter Wachstum verhält.
Ein System, das heute leicht zu verstehen ist, kann in sechs Monaten schwer zu ändern sein, ohne dass sich die ursprüngliche Entscheidung falsch angefühlt hat.
2. Der reale Kostentreiber: Kopplung über Zeit
Technische Kosten entstehen selten durch einzelne große Fehler, sondern durch schrittweise entstehende Kopplung.
Typische Beispiele:
- Ein Service kennt interne Datenstrukturen eines anderen Services
- Shared Models wachsen zu „God Objects“
- Business-Logik verteilt sich über mehrere Layer ohne klare Ownership
Am Anfang funktioniert das problemlos. Die Kosten entstehen erst, wenn Änderungen notwendig werden.
3. Änderungen sind der eigentliche Stresstest
Architektur zeigt ihren wahren Zustand nicht im Normalbetrieb, sondern bei Änderungen.
Ein gutes System erkennt man daran, dass:
- Änderungen isoliert möglich sind
- Unklar ist, wo eine Änderung implementiert werden muss
- Refactorings lokal bleiben und nicht das ganze System betreffen
Ein schlechtes System zeigt das Gegenteil: kleine Änderungen erzeugen große Nebenwirkungen.
4. Abstraktion als zweischneidiges Werkzeug
Abstraktionen sollen Komplexität reduzieren, erzeugen aber selbst Komplexität, wenn sie zu früh oder falsch eingesetzt werden.
Ein typisches Muster:
- Generische Interfaces werden vor konkreten Anforderungen gebaut
- Schichten entstehen ohne echte Variationspunkte
- Flexibilität wird angenommen statt benötigt
Das Ergebnis ist oft ein System, das flexibel aussieht, aber in der Praxis schwer zu ändern ist, weil die Abstraktion selbst zur Barriere wird.
5. Architekturkosten sind keine Performancekosten
Ein häufiger Denkfehler ist die Gleichsetzung von technischer Qualität mit Performance oder Stabilität zur Laufzeit.
Die eigentlichen Kosten liegen jedoch in der Entwicklungsgeschwindigkeit:
- Wie schnell kann ein neues Feature integriert werden
- Wie viel Code muss verstanden werden, um eine Änderung zu machen
- Wie oft entstehen ungewollte Seiteneffekte
Architektur ist damit weniger ein Runtime-Thema als ein Change-Enablement-Thema.
6. Wachstum verschärft jede Entscheidung
Mit zunehmender Systemgröße verstärken sich kleine architektonische Entscheidungen.
Was in einem kleinen Codebase tolerierbar ist, wird in einem größeren System teuer:
- Unklare Modulgrenzen
- Versteckte Abhängigkeiten
- Fehlende Ownership von Logik
Das System wird nicht plötzlich schlecht. Es wird schwerer zu verändern.
Fazit
Gute Architektur erkennt man nicht daran, wie elegant sie am Anfang wirkt, sondern daran, wie wenig sie zukünftige Änderungen verteuert.
Die wichtigste Kennzahl ist nicht Struktur oder Sauberkeit im Moment, sondern die Kosten jeder weiteren Anpassung.
Schreibe einen Kommentar