Architecture Decision Records Teil 2 - Das strukturierte Format für Architekturentscheidungen

Basierend auf meinen Erfahrungen lohnt es sich zwei Dinge zu dokumentieren.

Zum Ersten finde ich es wichtig in einem Team Klarheit über die Technologientscheidungen zu haben. Wir sind alle Individuen mit bestimmten Vorlieben. In meinem jetzigen Team haben wir ein buntes Gemisch aus Technologiepräferenzen. Um unbewusste Ablehnung von implementierten Lösungen durch andere Teammitglieder zu vermeiden und um Klarheit über den Entscheidungsvorgang zu bekommen, dokumentieren wir diese Entscheidungen.

Außerdem dokumentieren wir alle Architekturentscheidungen. Aber was ist das eigentlich genau? Dafür lohnt sich eine Definition, denn Softwarearchitektur selbst ist schon ein schwieriger Begriff.

Architekturentscheidungen sind immer ein Kompromiss aus verschiedenen Qualitätsanforderungen. Letztere sollten priorisiert vorliegen, so dass die Entscheidungen immer zugunsten der höher Priorisierten getroffen wird. Das ist wichtig, da es oft zum Konflikt zweier Qualitätsanforderungen kommt.

Dazu ein kleines Beispiel: Das Softwaresystem soll als Priorität 1 hohe Security bereitstellen. Außerdem soll es für den Benutzer leicht zu bedienen sein als Priorität 2. Es steht die Entscheidung an, wie die Benutzerauthentifizierung passieren soll. Hohe Sicherheit bietet die Zwei-Faktor-Authentifizierung, die aber dummerweise für den Benutzer etwas umständlicher ist als die Kombination Benutzername und Passwort. Hier schlägt Priorität 1 die Priorität 2 und es wird die Zwei-Faktor-Authentifizierung implementiert!

Für mich müssen die folgenden Anfordungen an die Dokumentation einer Entscheidung erfüllt sein:

In diesem Blog habe ich beschrieben, wie Entscheidungen strukturiert mit dem ADR-Template dokumentiert werden können.

Im nächsten Post gehen wir auf das arc42 Architekturdokumentationstemplate ein und sehen uns an, wie wir dort die Architecture Decision Records einsetzen.