Software Architektur-Entscheidungen werden von Architekten und agilen Teams häufig gefällt, jedoch selten dokumentiert. Lies hier, wieso es sich lohnt Architectural Decision Records (ADR) zu erstellen.
In vielen Software-Entwicklungs-Teams, in denen ich gearbeitet habe, wurden gefällte Architektur-Entscheide selten dokumentiert. Dies führte oft dazu, dass sich die Leute an unterschiedliche Gründe erinnerten, weshalb der Entscheid so gefällt wurde. Zudem war sich das Entwicklungsteam nicht immer bewusst, dass es sich um eine Architekturentscheidung handelt, da die Rolle des Architekten in Embedded-Software-Teams häufig nicht vorhanden ist.
Je nach Team und den beteiligten Charakteren, traten so immer wieder Diskussionen über dieselben Entscheide auf. Dies ist nicht effizient und kann energieraubend sein. Oder ein Management-Mitglied bekommt unterschiedliche Aussagen, weshalb das Team sich für diesen Weg entschieden hat.
Was ADRs sind?
Im CAS Software-Architecture habe ich glücklicherweise von den ADRs erfahren. ADRs sind ein wichtiger Teil deiner Architekturdokumentation. Ein Architectural Decision Record (ADR) ist ein Dokument, das eine bestimmte Architekturentscheidung in deinem Projekt beschreibt und die Gründe dafür erläutert. Es dient als Nachweis dafür, dass eine Entscheidung bewusst und aufgrund von konkreten Überlegungen getroffen wurde und nicht zufällig oder aufgrund von persönlichen Präferenzen.
So sieht ein ADR konkret aus
Ein ADR besteht aus einer Überschrift, die das zu lösende Problem benennt, einer Beschreibung der gewählten Lösung, einer Liste von in Erwägung gezogenen Optionen mit deren Pros und Contras und einer Erklärung der Gründe, warum die ausgewählte Lösung unter den beschriebenen Umständen die beste Wahl ist.
Templates für einen solchen ADR findet man viele im Internet. Es gibt sogar ADR Manager und weiter unterstützende Tools.
Was hat das Verwenden von ADR in meinem Team verändert?
In meinem aktuellen Projekt-Team arbeiten wir agil. Somit werden Entscheidungen nicht zu sehr «Upfront» gefällt, sondern wenn immer nötig.
Wir haben uns entschieden die meisten ADR im Entwicklungs-Team gemeinsam zu erarbeiten. So kann jedes Team-Mitglied seine bevorzugte Option zu der Problemstellung einbringen und in der Gruppe werden dann die Pros und Contras erarbeitet, der Entscheid gefällt und die Begründung dazu dokumentiert. Gegenüber dem Top-Down-Ansatz, bei dem der Architekt die Entscheidung vorgibt, ist der Vorteil dieser Methode, dass sich die Entwickler mit dem Entscheid identifizieren können.
Das heisst natürlich nicht, dass alle mit jedem Entscheid 100% einverstanden sind. Aber so ein Entscheid ist immer ein Kompromiss. Wichtig dabei ist, dass die Entwickler im Entscheidungsprozess eingebunden sind.
Wo ADRs hingehören
ADRs legst du am besten in deiner Architekturdokumentation ab. Wenn du deine Dokumentation z.B. nach Arc42 aufgebaut hast, findest du bereits ein entsprechendes Kapitel dazu.
Deine Entscheidungen sollten möglichst kurz und prägnant geschrieben werden, damit du diese gelesenen werden und niemand abgeschreckt wird.
Fazit
Seit der Einführung der ADRs sind in meinem Team die Entscheidungen bewusster gefällt und sauber dokumentiert worden.
Insgesamt sind ADRs ein nützliches Werkzeug, um Architekturentscheidungen im Projekt zu dokumentieren und zu verstehen, warum bestimmte Entscheidungen getroffen wurden. ADRs helfen dir dabei, die Kommunikation und Zusammenarbeit innerhalb deines Teams zu verbessern und sicherzustellen, dass Entscheidungen fundiert und nachvollziehbar sind.
