Falle #16 Nur das Architekturdiagramm

Wir alle haben gesehen, Praktiker Wir präsentieren ein sorgfältig entworfenes Architekturdiagramm, das zeigt, wie einige Elemente eines Systems in Zukunft miteinander in Beziehung stehen sollen. Wir betrachten das Bild ehrfürchtig und bewundern die Eleganz. Dann machen wir uns daran, ein System zu erstellen, das nur oberflächliche Beziehungen zum Diagramm aufweist.

Warum? Alles, was eine nützliche Architektur fehlte:

• Lücken, die anzeigen, welche Änderungen erforderlich sind
• Kontrollen, die Risiken für das Unternehmen mindern
• Spezifikationen, die Designer, Implementierer, Betreiber und zukünftige Architekten einschränken
• alles, was hervorhebt, wie das zukünftige Ökosystem einen besseren Wert liefern wird als das, was wir heute haben

Diese sorgfältig erstellten Diagramme stellen typischerweise einen Teil des gesamten Ökosystems dar. Zu oft sind die Diagramme voller willkürlicher Designentscheidungen, die die Vorurteile des Praktikers untermauern sollen.

Eine gute Architektur unterstützt fundierte Entscheidungen während des Architekturentwicklungsprozesses und schränkt Design, Implementierung und operative Entscheidungen ein. Ein Diagramm kann diese Aufgaben übernehmen.

Man kann nicht von einer Box und Linie aus regieren

Bildbasierte Darstellungen verhindern üblicherweise das umfassende Verständnis der Stakeholder, Entscheidungsträger und Hauptbeteiligten, das sich während der Entwicklung entwickelt. Dieser Schaden entsteht, weil nur wenige Diagramme mehr als ein einzelnes Anliegen darstellen können. Wenn wir uns auf diese Diagramme konzentrieren, vermeiden wir implizit komplexe Kompromisse und fixieren uns auf eine einzige Optimierung.

Diagramme, die sich als Architektur ausgeben, stecken voller ungerechtfertigter Spezifikationen und Kontrollen. Ungerechtfertigt, weil die Regel nur ‘für sich allein’ steht. Kontextlos spezifiziert das Diagramm einen Dienstanbieter, eine Software oder einen Betriebsstandort. Gute Architekten erkennen dies und müssen den Aufschrei „Warum?“ unterdrücken.

Best Practice verknüpft eine Spezifikation explizit mit einem Ziel, einer Zielsetzung oder einer anderen Anforderung und die Designentscheidung mit der Spezifikation. Wie können wir ohne diese Verknüpfung die Eignung der Designentscheidung für die Zielsetzung beurteilen?

Wir alle kennen die Ausrede: ‘Aber das Diagramm ist nur eine Ansicht.’ In unserer EA-Fähigkeitspraxis verdrehen wir die Augen. Wenn es sich um eine Architekturansicht Wo befindet sich das Repository, das die Informationen enthält, die Anliegen, Anforderungen, Präferenzen, Beziehungen und Analysen hervorheben? Sie haben es im Kopf des Praktikers erraten, wo Peer-Review und Wiederverwendung unmöglich sind.

Conexiam Navigieren nutzt das Solution Development Notebook (SDN), um die Change- und Implementierungsteams aktiv zu unterstützen und Portfoliomanagern die Steuerung von Change-Initiativen und die Messung des Nutzens zu erleichtern. In jedem SDN muss der Architekt die wesentlichen Leitlinien für den Implementierer, den Eigentümer und den Portfoliomanager identifizieren.