Architektur

Lebensfähigkeit in fünf Pflichten

Architektur ist die Struktur, die entscheidet, wie änderbar, wie robust und wie verständlich ein System ist. Lebensfähigkeit bedeutet: Ist die Architektur noch Herr über ihre eigene Komplexität — oder hat die Komplexität längst übernommen?

Pflicht 1

Architekturreason

Nicht verhandelbar

Warum existiert diese Komponente? Jede Komponente hat einen Zweck — nicht eine historische Erklärung. Org-Chart ist kein Architekturgrund.

Typischer Bruch

Komponenten existieren wegen alter Org-Grenzen, nicht wegen Funktionen. Conway’s Law ohne Bewusstsein.

Pflicht 2

Versionierte Architektur

Nicht verhandelbar

Architektur-Entscheidungen (ADRs) datiert und begründet. Wenn die Architektur sich verändert hat und niemand es dokumentiert hat, regiert die mündliche Überlieferung.

Typischer Bruch

Architekturdiagramme veralten still. Das aktuelle System sieht niemand — jeder hat ein anderes Bild im Kopf.

Pflicht 3

Explizite Schnittstellen

Nicht verhandelbar

Jede Schnittstelle ist explizit im Datenmodell, nicht nur im Diagramm. Kopplungsgrad, Latenz, Durchsatz, Fehlerrate — messbar. Schnittstellen sind die Bruchstellen jeder Architektur.

Typischer Bruch

Schnittstellen leben nur in Köpfen und Diagrammen. Wenn der eine Entwickler geht, weiß niemand mehr, was über die Schnittstelle läuft.

Pflicht 4

Schwächste Stelle

Was prüfen

Welche Komponente, welche Schnittstelle reißt zuerst? Der schwächste Punkt der Architektur — nicht die durchschnittliche Robustheit. Single Point of Failure sichtbar machen, nicht mitteln.

Typischer Bruch

„Architektur ist insgesamt solide.“ Vielleicht. Aber die eine zentrale Komponente, durch die alles läuft, ist der verdeckte Single Point of Failure.

Pflicht 5

Wandelbarkeit

Was prüfen

Reaktionszeit zwischen neuer Anforderung und Architektur-Anpassung. Wie teuer ist eine Änderung? Aus Versionshistorie messbar. Starre Architektur ist langsamer Tod.

Typischer Bruch

Jede Änderung kostet Monate, weil alles mit allem verkoppelt ist. Die Architektur ist nicht beweglich — sie ist erstarrt und merkt es nicht.

Realer Fall — Conway lässt grüßen: Architektur spiegelt Org-Chart

Beobachtung: Ein System wuchs über zehn Jahre, die Architektur spiegelt exakt die (mehrfach umorganisierte) Abteilungsstruktur — nicht den Produkt-Zweck. Pflicht 1 verletzt: Viele Komponenten existieren wegen alter Org-Grenzen, nicht wegen Funktionen. Pflicht 3 verletzt: Schnittstellen waren nur in Diagrammen, nicht im Datenmodell — bei jeder Reorganisation neu „entdeckt“. Pflicht 4 verletzt: Der verdeckte Single Point of Failure war eine Alt-Komponente, durch die historisch alle Abteilungen kommunizierten. Die Methode macht Conways Gesetz sichtbar — und nutzbar.

Eine Architektur, die ihre Schnittstellen versteckt, versteckt ihre Bruchstellen. Komplexität, die nicht sichtbar ist, ist nicht beherrscht — sie ist nur vertagt.

Methode entwickelt von Thomas Arends · OTSM (Organisations-, Technologie- und Service-Management) GmbH.