Architektur-Review

Ob eine Architektur trägt, entscheidet sich nicht im Diagramm, sondern im Betrieb: beim Release, unter Last, bei der nächsten Anforderung. Das Review hält das Diagramm gegen den Betrieb und findet nebenbei die Schichten, die wegkönnen.

Sie erkennen sich, wenn …

• Der Letzte, der das ganze System überblickte, hat es längst verlassen.
• Jede neue Anforderung landet als weitere Schicht auf den bestehenden.
• Die Architektur existiert doppelt: einmal im Wiki, einmal in Wirklichkeit.
• Ausfälle verlaufen unvorhersehbar: kleine Ursache, großer Schaden.

Was ich untersuche

Die tatsächliche Architektur, nicht die dokumentierte: Abhängigkeiten und Kopplung, den Weg eines Releases vom Commit bis in die Produktion und die Schichten dazwischen. Oft beginnt die Kette ganz oben, im Frontend, bei einem falsch gewählten oder falsch angewendeten Framework, das Werkzeug um Werkzeug nach sich zieht, bis hinunter in die Docker-Images. Dazu die Frage, die gemeinhin niemand stellt: Was davon trägt, und was wird bloß mitgetragen?

Was am Ende steht

Ein schriftlicher Befund: Ursachen mit Belegen, Maßnahmen priorisiert, vom pragmatischen Schritt bis zur schlanken Ziellösung. Wie ich messe und was der Befund enthält, steht unter Wie ich diagnostiziere.