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?
1Pflicht 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.
2Pflicht 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.
3Pflicht 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.
4Pflicht 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.
5Pflicht 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.