Architekturentscheidungen

Gastautor Jürgen Dufner:

Kennen Sie den Satz: „Das ist historisch so gewachsen.“ Das ist die Antwort auf eine der folgenden Fragen in der Softwareentwicklung: „Wie hat sich die Architektur so entwickelt?“ oder „Warum wurde das so gebaut?“. Häufig entsteht so eine Situation, wenn neue Kollege*innen ins Team kommen und erfahrene Kolleg*innen erklären wie die Softwarearchitektur ist. Sie ist das Ergebnis einer Summe von bewussten und unbewussten prägenden Entscheidungen, die sich nicht mehr nachvollziehen lassen. Historisch gewachsen eben. Die aktuelle Situation ist in vielen Fällen nicht mehr zufriedenstellend. Im folgenden Text finden Sie einen Ansatz um solche Fragen zu vermeiden.

Softwarearchitektur ist die Summe von Entscheidungen

Für Softwarearchitektur gibt es eine Vielzahl von Definitionen. Einige davon fokussieren auf der Tatsache, dass eine Architektur nicht von alleine zustande kommt, sondern dass Software gebaut wird und dabei Entscheidungen getroffen werden. Basierend auf dieser Definition stellt sich die Frage: „Welche Entscheidung muss ich beim Bauen der Software treffen, damit ich zu einer guten Architektur komme?“ und „Was ist für meinen Kontext eine gute Architektur“? Diese Fragen können nur anhand der Qualitätsziele der zu erstellenden Software beantwortet werden. Die Softwarearchitekt*in und das Team müssen die Qualitätsziele kennen und priorisiert haben. Weiterhin müssen sie die Randbedingungen kennen, die sie in ihrer Entscheidungsfreiheit einschränken. Dieses Thema „Qualitätsziele und Randbedingungen“ werde ich in einen weiteren Blogbeitrag erläutern.

Was sind typische Architekturentscheidungen?

• Welche Programmiersprache oder welches Framework soll verwendet werden?
• Wie schneiden wir die Packages?
• Für welchen Bounded Context bauen wir einen oder wie viele Services?

Zeitpunkt einer Architekturentscheidung

Hier gilt die alte Weisheit: Es kommt darauf an, mit anderen Worten: „So spät wie möglich, aber so früh wie nötig.“ Je später die Entscheidung getroffen werden kann, umso mehr Informationen liegen i.d.R. vor, aber leider sind Architekturentscheidungen oft von so grundlegender Natur, dass sie unter Unwissenheit, also teilweise sehr früh getroffen werden müssen. Bevor eine Architekturentscheidung getroffen wird, müssen sich die Entscheider*innen zuerst fragen, ob diese Entscheidung jetzt getroffen werden muss oder ob sie auf einen späteren Zeitpunkt verschoben werden kann.

Strategie einer Architekturentscheidung

Die Art und Weise wie eine Architekturentscheidung zustande kommt ist abhängig von vielen Faktoren: Zusammenarbeit der Softwarearchitekt*in mit dem Softwareentwicklungsteam, Stakeholder, Entscheidungsgegenstand, Firmenkultur, gesetzliche und regulatorische Randbedingungen, Architekturprinzipien und -richtlinien übergeordneter Architekten etc. Interessant ist aber besonders die Frage: Trifft die Architekt*in die Entscheidung alleine oder gemeinsam mit dem Entwicklungsteam?

Aus meiner Erfahrung kann ich sagen, dass ich es schlecht finde, wenn die Architekt*in alleine entscheidet und das Entwicklungsteam die Entscheidung umsetzen soll. Das hat den Nachteil, dass sie zum Flaschenhals wird, weil alles über sie laufen muss. Außerdem fließt dann nur ihr Wissen und ihre Erfahrung in die Entscheidung ein. Dadurch gäbe es nur eine geringe Identifikation des Entwicklungsteams mit der Entscheidung, ggf. gibt es sogar Widerstände, weil sich das Team übergangen fühlt. Das Ergebnis wäre wahrscheinlich eine mangelhafte Umsetzung der gewünschten Architektur. Es ist besser, wenn die Architekt*in auf Grund ihrer kommunikativen Fähigkeiten und ihres technischen und fachlichen Wissens das Entwicklungsteam überzeugt und gemeinsam entscheiden. Dadurch kommt automatisch eine gute nachhaltige Entscheidung zustande, weil das Entwicklungsteam über ein beträchtliches Wissen und Erfahrung verfügt, das auf diese Weise bei der Entscheidung berücksichtigt wird.

Die Dynamik des Entscheidungskontexts

Ist eine Entscheidung getroffen, dokumentieren die Architekt*in und das Team die Entscheidung. Diese Aufgabe könnte leicht vergessen werden, weil alle an der Entscheidung mitgewirkt haben und auch alle darüber informiert sind.

Bei fehlender Dokumentation geht der Kontext in dem die Entscheidung stattgefunden hat, verloren. Das System ist dann historisch gewachsen, weil sich im Laufe der Zeit der Kontext geändert hat. Der Kontext spiegelt den aktuellen Wissensstand und die aktuellen Annahmen wieder, die in die Entscheidung eingeflossen sind. Weitere Einflussfaktoren sind die Erfahrung der Architekt*in oder des Entwicklungsteams, der Drang etwas Neues ausprobieren zu wollen, neuste Erkenntnisse aus einem Konferenzbesuch oder auch aktuelle Trends und Moden der IT und Softwarearchitektur. Das können alles Einflussfaktoren auf die Architekturentscheidungen sein.

Dokumentieren sie Architekturentscheidungen

Gerade darum ist es wichtig die Architekturentscheidung festzuhalten, dass später reflektiert werden kann, warum eine spezielle Entscheidung getroffen wurde. In diese Dokumentation der Architekturentscheidung (engl. Architecture Decision Record, kurz ADR) gehören aus meiner Erfahrung folgende Dinge:

1. Titel – Der Titel der Architekturentscheidung
2. Kontext – Der Kontext in dem die Entscheidung stattgefunden hat. Dazu zähle ich die Qualitätsziele auf die diese Entscheidung einzahlt und gegebenenfalls auch auf die es kontraproduktiv wirkt. Ich erwarte im Kontext die Randbedingung, die einzuhalten sind und die natürlicherweise den Entscheidungsspielraum eingrenzen. Hinzukommen die berücksichtigten Alternativen, sofern keine vorliegen, ist es keine Entscheidung sondern ein Zwang. Weiter sind hier die Annahmen zu finden, die der Entscheidung zugrunde lagen. Zu guter Letzt wird hier auch der Entscheidungsgegenstand erläutert, über den entschieden wurde.
3. Entscheidung – Die Architekt*in und das Teams formulieren die Entscheidung in aktiver Sprache. Das ist eine eindeutige Willensbekundung.
4. Status – Eine Liste von Status, die bei allen Entscheidungen verwendet wird: Vorgeschlagen (=Entscheidung vorbereitet, aber noch nicht getroffen), Akzeptiert (=Entscheidung getroffen), Veraltet (=Entscheidung ist überholt und durch eine neuere ersetzt worden, mit einer Referenz auf die neue Entscheidung).
5. Konsequenzen und Risiken – Hier sollen alle Erwartungen, die voraussichtlich durch die Entscheidungen eintreffen, dokumentiert werden. Auch wenn es sich nur um Vermutungen oder Risiken handelt, deren Eintrittswahrscheinlichkeit nicht geschätzt ist. Es bietet sich an, die Konsequenzen selbst nochmal in positiv, neutral und negative Konsequenzen zu unterteilen um einen besseren Überblick zu haben.

Das Format der Architekturentscheidung kann eine einfache Punkteliste sein, wie oben gezeigt. Diese kann im Wiki oder als Markdown- oder Asciidoc-Datei beim Quellcode gespeichert werden. Gerade letzteres kommt einem Team entgegen, das sich schon für Doc-as-Code entschieden hat.

Fazit

Softwarearchitektur ist die Summe von Architekturentscheidungen. Diese werden teilweise bewusst, teilweise unbewusst getroffen, oft jedoch nicht nachhaltig dokumentiert. Für eine nachhaltige Softwarearchitektur kennen sie die Qualitätsziele und Randbedingungen. Die Architekturentscheidungen werden gemeinsam von der Architekt*in und dem Team getroffen. Sie dokumentieren den Kontext, die Entscheidung und die Konsequenzen. Auf diese Weise ist nachvollziehbar, wie es zu dieser Architektur gekommen ist.

Vielen Dank an Bernd Faßbender und Mathias Born für die Gespräche und ihre Kommentare zu früheren Fassungen dieses Artikels.

Referenzen

• Michael Nygard: Documenting Architecture Decisions, http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions
• ThoughtWorks Technology Radar, https://www.thoughtworks.com/de/radar/techniques/lightweight-architecture-decision-records