Architecture Decision Records Teil 3 - Im Kontext von arc42

Wird die Architekturdokumentation gerade erstellt, sollte anders vorgegangen werden. Ralf und ich haben dazu im weiter unten verlinkten Talk die folgende Bearbeitungsreihenfolge für die Kapitel vorgeschlagen:

1 → 2 → 3 → 10 → 9 → …​

Kapitel 1-3 sind notwendig, um festzulegen WAS gebaut werden soll, WELCHE Randbedingen nicht änderbar sind und in WELCHEM Kontext das zu bauende System operiert. Im Grund genommen ist es der Vertrag, der mit Kunden geschlossen wird.

Bevor nun die Architektur entworfen werden kann, ist es sinnvoll die Qualitätsanforderungen abzuklären. Das Ergebnis sollte ein gewichteter Qualitätsattributbaum sein, der die maximal fünf höchstpriorisierten Qualitätsattribute enthält. Die folgende Abbildung zeigt einen Ausschnitt eines solchen Baumes für ein System, das ich betreut habe.

Für das System dieses Qualitätsattributsbaumes waren die Qualitätsattribute sehr klar, dank zweier Fachexpert*innen, die sich in ihrem Bereich und mit dem abzulösenden Altsystem sehr gut auskannten. In den meisten Fällen wird es eher darauf hinauslaufen mit unklaren Qualitätsanfordungen wie "Das System mus performant sein!" konfrontiert zu werden. Oder es werden mehrere sich widersprechende Qualitätsattribute gefordert. Hier hilft es Vergleiche mit anderen Systemen heranzuziehen. Im Falle von Performanz kann von Kundenseite zum Beispiel ein System benannt werden, dass als performant empfunden wird.

Erst jetzt kann ich daran gehen die Architektur zu entwerfen und die Entwurfsentscheidungen als ADRs zu dokumentieren. Es empfiehlt sich am Ende eines jeden ADRs eine weitere Überschrift einzufügen in der die, von der Entscheidung betroffenen, Qualitätsattribute aus Kapitel 10 verlinkt werden.

Lesende interessieren sich normalerweise nicht dafür auf welcher Grundlage ein System gebaut wurde. Viel interessanter ist doch zu sehen WIE es aufgebaut ist. Architekturdiagramme wie die Microservicearchitektur von Netflix zum Beispiel wirken imposant und eindrucksvoll. Die Kompromisse im Betrieb und die Komplexität im Entwicklungs- und Deploymentprozess treten in den Hintergrund.

Für Softwarearchitekturschaffende oder falls es Probleme gibt sind Kapitel neun und zehn aber hochinteressant. Denn dort steht im besten Fall nachvollziehbar WARUM ein System so gebaut ist und welche Entwurfsentscheidungen dazu geführt haben, dass ein gewisses Problem aufgetreten ist. Nicht selten sind unklare Qualitätsanforderungen die wahre Ursache für Schwächen des Systems!