Architektur kostet zu viel Zeit

Es klingt vernünftig.

„Wir haben gerade keine Zeit für Architektur.“

Meistens heißt das nicht: Wir sparen Zeit.

Meistens heißt es: Wir verschieben Entscheidungen.

Und verschobene Architekturentscheidungen verschwinden nicht. Sie tauchen später wieder auf — als Kopplung, als schwer testbarer Code, als unklare Zuständigkeit, als endlose Abstimmung, als Angst vor Änderungen.

Architektur kostet Zeit. Aber fehlende Architektur kostet auch Zeit.

Nur steht sie selten am Anfang auf dem Plan.

Der Denkfehler

Der Denkfehler besteht darin, Architektur als zusätzliche Arbeit zu betrachten.

Erst kommt das Feature. Dann kommt Architektur. Wenn noch Zeit ist.

So funktioniert Software aber nicht.

Jede Codebasis bekommt eine Struktur. Auch dann, wenn niemand sie bewusst entwirft. Dateien liegen irgendwo. Komponenten kennen irgendwen. Daten fließen irgendwie. Seiteneffekte passieren irgendwo. Entscheidungen werden trotzdem getroffen — nur implizit, lokal und oft widersprüchlich.

Keine Architektur ist deshalb nicht neutral.

Keine Architektur ist auch eine Architektur. Meistens eine zufällige.

Der Big Ball of Mud entsteht selten durch eine einzelne schlechte Entscheidung

Ein Big Ball of Mud entsteht selten an einem Dienstag um 14:37 Uhr, weil jemand beschlossen hat:

„Heute bauen wir ein unwartbares System.“

Er entsteht durch viele kleine Entscheidungen, die einzeln vernünftig wirken.

Ein schneller Fix. Eine Ausnahme, nur für dieses Feature. Eine Abhängigkeit, die später wieder entfernt wird. Ein direkter Zugriff, weil es gerade einfacher ist. Eine Komponente, die noch eine weitere Verantwortung übernimmt. Ein Service, der noch ein bisschen mehr weiß, als er wissen sollte.

Jede Entscheidung spart kurzfristig Zeit.

Zusammen erzeugen sie ein System, in dem Änderungen immer mehr Kontext benötigen. Irgendwann muss man nicht mehr nur das Feature verstehen, sondern die Geschichte aller Abkürzungen, die davor genommen wurden.

Das ist der Moment, in dem Geschwindigkeit kippt.

Nicht weil das Team plötzlich schlechter wird. Sondern weil die Struktur jede Änderung verteuert.

Architektur ist Risikomanagement

Gute Architektur ist nicht der Versuch, die Zukunft perfekt vorherzusagen.

Das wäre Overengineering.

Gute Architektur bedeutet, die Stellen bewusst zu gestalten, an denen spätere Änderung wahrscheinlich oder teuer ist.

Wo liegen fachliche Grenzen? Wer besitzt welchen Zustand? Welche Daten dürfen in welche Schicht? Wo passieren Seiteneffekte? Was ist ein Command, was ist Read-State? Was ist UI-Zustand, was ist fachlicher Zustand? Welche Teile dürfen voneinander wissen — und welche nicht?

Das sind keine akademischen Fragen.

Das sind Fragen, die bestimmen, ob eine Änderung lokal bleibt oder durch die halbe Anwendung diffundiert.

Gute Grenzen sparen später Arbeit

Grenzen kosten am Anfang ein wenig Aufmerksamkeit.

Aber sie sparen später Abstimmung.

Wenn klar ist, welches Modul welche Verantwortung hat, muss nicht jedes Feature neu verhandeln, wo Logik hingehört. Wenn ein ViewModel klar vom DTO getrennt ist, muss nicht jede API-Änderung bis ins Template auslaufen. Wenn Seiteneffekte nicht irgendwo in Komponenten versteckt sind, lassen sie sich testen, beobachten und umbauen.

Architektur ist hier kein großes Elfenbeinturm-Diagramm.

Architektur ist die Antwort auf die Frage:

Was muss stabil bleiben, damit Änderung billig bleibt?

Overengineering ist real

Natürlich kann Architektur zu groß werden.

Man kann Abstraktionen bauen, bevor ein Problem existiert. Man kann Patterns stapeln, um einfache Dinge wichtig aussehen zu lassen. Man kann ein Team mit Regeln lähmen, die niemand erklären kann. Man kann aus „Architektur“ eine Rechtfertigung machen, nichts auszuliefern.

Das ist real.

Aber Overengineering ist kein Argument gegen Architektur.

Es ist ein Argument gegen schlechte Architektur.

Die Alternative zu übertriebener Architektur ist nicht gar keine Architektur. Die Alternative ist leichtgewichtige Architektur: sichtbar, überprüfbar, teamfähig und veränderbar.

Leichtgewichtig heißt nicht beliebig

Leichtgewichtige Architektur bedeutet nicht:

„Macht, was ihr wollt.“

Sie bedeutet:

• wenige, klare Regeln
• explizite Verantwortlichkeiten
• überprüfbare Grenzen
• kurze Feedbackzyklen
• Architekturentscheidungen, die im Code wiederzufinden sind

Eine gute Architekturregel ist nicht gut, weil sie in einem Dokument steht.

Sie ist gut, wenn sie im Alltag hilft: beim Review, beim Testen, beim Refactoring, beim Onboarding, beim Ändern.

Das Problem ist nicht die erste Abkürzung

Abkürzungen sind manchmal richtig.

Ein Prototyp darf anders aussehen als ein Produkt. Ein Experiment braucht nicht sofort dieselbe Struktur wie ein langlebiger Kernprozess. Ein Team darf lernen, bevor es endgültige Grenzen zieht.

Das Problem beginnt, wenn temporäre Entscheidungen dauerhaft werden, ohne dass jemand sie erneut bewertet.

Dann wird aus „nur diesmal“ ein Muster. Aus dem Muster wird Gewohnheit. Aus der Gewohnheit wird Architektur.

Nur nennt sie niemand so.

Der eigentliche Preis

Fehlende Architektur macht nicht die erste Lieferung teuer.

Sie macht die zehnte Änderung teuer.

Sie macht nicht den ersten Button schwierig.

Sie macht den Moment schwierig, in dem derselbe Zustand von drei Seiten, zwei Stores, einem Resolver, einem Effect und einer Komponente verändert wird.

Sie macht nicht das erste DTO gefährlich.

Sie macht den Moment gefährlich, in dem API-Strukturen unkontrolliert in Templates, Forms und Komponentenlogik eingebrannt sind.

Sie macht nicht den ersten Shortcut schlimm.

Sie macht den Punkt schlimm, an dem niemand mehr weiß, welche Shortcuts noch aktiv sind.

Der bessere Satz

Statt zu sagen:

„Architektur kostet zu viel Zeit.“

sollten wir genauer sagen:

„Wir müssen entscheiden, wie viel Struktur dieses Problem jetzt braucht, damit wir später noch ändern können.“

Das ist eine andere Diskussion.

Sie ist weniger religiös. Sie ist weniger heroisch. Und sie ist deutlich ehrlicher.

Architektur ist kein Selbstzweck. Architektur ist auch kein Ersatz für Produktverständnis.

Aber fehlende Architektur ist keine Geschwindigkeit.

Sie ist ein Kredit.

Und der Big Ball of Mud ist die Rechnung.