Architektur- und Fachentscheidungen

Täglich treffen wir in unseren Projekten Entscheidungen, die Einfluß auf die Aufgabenangemessenheit des Produktes haben, das wir gerade erstellen. Selbst kleine Entscheidungen, wie die Benennung oder Positionierung einer Schaltfläche in einem Software-Dialogsystem, können einen relativ großen Einfluss auf die Alltagstauglichkeit des Systems haben. Bei der Benennung einer Schaltfläche kommt uns zugute, dass wir die einmal getroffene Entscheidung leicht revidieren und verbessern können. Andere Entscheidungen, wie z.B. die Entscheidung zur Verwendung eines Rich-Clients im Gegensatz zum Web-Browser, lassen sich nicht so einfach zurücknehmen. Im Gegenteil, häufig sind Entscheidungen, die mit einem strategischen Betrachtungshorizont getroffen werden, schwierig zurückzunehmen und haben eine längere Lebensdauer als das Projekt, in dem die Entscheidung getroffen wurde. Dabei ist unerheblich, ob die Entscheidungen in die Fach- oder die Technikdomäne des Projektes fallen. Nachfolgend mache ich Vorschläge, unter welchen Prämissen strategische Entscheidungen in einem Projekt getroffen werden und wie sie dokumentiert und kommuniziert werden können. Dabei gehe ich sowohl auf technische als auch auf fachliche Fragestellungen ein.

Den teamorientierten Kommunikationsprozess auf dem Weg zur Entscheidung und die Verantwortlichkeit für die getroffene Entscheidung behandle ich hier nicht – das ist ein separates Thema.

Architekturentscheidungen

Technische Entscheidungen, die mit strategischem Betrachtungshorizont getroffen werden, bezeichnen wir als Architekturentscheidungen. Für Softwaresysteme werden diese Entscheidungen unter den folgenden Prämissen getroffen:

  • Vertretung der Interessen aller Stakeholder am System über den gesamten Lebenszyklus.
  • Minimierung der Gesamtkosten für das System über den gesamten Lebenszyklus.

Architekturentscheidungen sollen die Abhängigkeiten der Systemkomponenten zueinander minimieren (vgl. Quasar Architekturstil). Es ist die Architektur, die es erlaubt, ein Softwaresystem an veränderliche Anforderungen anzupassen. Während Architekturentscheidungen einen Lösungsraum aufspannen, strukturieren Designentscheidungen, die auf taktischer und operativer Ebene getroffen werden, diesen Lösungsraum. Manche Designentscheidungen werden ausschließlich aus dem Kontext einer zuvor getroffenen Architekturentscheidung abgeleitet. Genau deshalb sind Architekturentscheidungen schwierig zu revidieren, weil ihre Änderung zu einer Änderungskaskade bei den abhängigen Designentscheidungen führt. Der Übergang zwischen Architektur- und Designentscheidung kann fließend sein, klar ist jedoch, dass viel weniger Architekturentscheidungen als Designentscheidungen getroffen werden. Während man in einem Projekt möglicherweise mit 20 oder weniger Architekturentscheidungen auskommt, können durchaus 100 und mehr Designentscheidungen nötig sein.

Die folgende Grafik visualisiert die fünf Disziplinen Strategie, Anforderungen, Architektur, Design und Implementierung als Aufgabenkomplexe, die bei jedem Softwareprojekt zu adressieren sind.

Architektur als Brücke zwischen Anforderungen und Umsetzung

Es gibt eine natürliche Reihenfolge der Disziplinen von links nach rechts sowie Übergänge von einer Disziplin zur nächsten. Die Strategie und daraus abgeleitete Anforderungen gehören zur Problemdomäne eines Vorhabens. Alles dreht sich um die Fragestellung: „Welches Problem – was – soll gelöst werden?“ Die Architektur wiederum ist Teil der Lösungsdomäne eines Projektes. In der Lösungsdomäne sucht man nach Antworten auf die Frage: „Wie kann die Lösung zu einem Problem erreicht werden?“ (vgl. dazu auch „Scrum und Architektur: Konzeptionelle Integrität im Scrum-Prozess“). Die Architektur übernimmt dabei eine Brückenfunktion zwischen der Problem- und der Lösungsdomäne.

In agilen Projekten ist ein Beobachtungs- und Anpassungsverhalten, also ein Lernverhalten, über sämtliche Disziplinen vorgesehen. In klassischen Softwareentwicklungsprojekten versucht man diesen Erkenntnisprozess so lange wie möglich zu negieren und über Change Requests teuer zu machen.

Zum heutigen Stand des Wissens gehört die Verschriftlichung des Diskurses, der zu einer Architekturentscheidung geführt hat. Dabei wird die Problemstellung, die getroffenen Annahmen, die berücksichtigten Randbedingungen und die betrachteten Alternativen sowie die Entscheidungsbegründung nachvollziehbar dokumentiert. Die Schriftform hat verschiedene Gründe:

  • Die Entscheidung wird bewusster getroffen.
  • Es wird größere Klarheit in der Formulierung gefordert und die Nachvollziehbarkeit der Überlegungen wird unterstützt.
  • Die Entscheidung wird erinnerbar und leichter kommunizierbar.
  • Neu hinzukommende Projektmitglieder haben eine Chance, getroffene Entscheidungen nachzuvollziehen.

Stefan Zörner schlägt vor, für die Dokumentation eine festgelegte Abfolge von Fragestellungen zu durchlaufen und zu beantworten. Dieses Vorgehen halte ich für ausgesprochen sinnvoll und wende es in allen meinen Projekten an. Im einzelnen sieht die Abfolge der Fragestellungen so aus:

Fragestellungen zur Dokumentation einer Architekturentscheidung

Den Ergebnistext kann man z.B. in einem Wiki festhalten. Aufwändig gestaltete Word-Formulare benötigt man dazu nicht. In meinen Projekten wird oft memYAK als web-basierte Kommunikationsplattform eingesetzt, dort steht ein eigenes Web-Formular zur Erfassung von Architekturentscheidungen zur Verfügung.

Die erfassten Entscheidungen sind in einer Liste zu führen, die für die Projektmitglieder jederzeit zugreifbar ist. Es ist darauf zu achten, die Dokumentation aktuell zu halten. Das gilt für überarbeitete und revidierte Entscheidungen ebenso, wie für neu getroffene Entscheidungen.

memYAK Formular zur Erfassung einer Architekturentscheidung
memYAK Beispiel einer Architekturentscheidung
memYAK Liste mit Architekturentscheidungen

Dieses Verfahren der Dokumentation von Architekturentscheidungen kann bei einem wasserfall-orientierten Vorgehen ebenso eingesetzt werden, wie bei agilen Vorhaben. Es kann nicht nur, es sollte sogar!

Fachentscheidungen

Fachentscheidungen liefern Antworten auf die Frage: „Welches Problem soll gelöst werden?“ Sie sind damit im Problemraum eines Vorhabens angesiedelt und sind komplementär zu den technischen Fragestellungen, die im Lösungsraum des Projektes verortet sind.

Wie wird mit fachlichen Entscheidungen umgegangen, die unter einem strategischen Blickwinkel getroffen werden? In klassischen Projekten manifestieren sie sich in der Projektvision und in den Fachkonzepten. Bei agilem Vorgehen stecken sie in der Produktvision und in den User Stories.

Während es üblich ist, die strategischen technischen Entscheidungen als Architekturentscheidungen zu dokumentieren, habe ich eine analoge Herangehensweise für strategische fachliche Entscheidungen bisher nicht beobachtet. Der zur Entscheidung führende Diskurs wird häufig nicht dokumentiert. Dabei lassen sich dieselben Gründe, die für eine Dokumentation von Architekturentscheidungen sprechen, auch für strategische Fachentscheidungen heranziehen. Zeitlich werden Fachentscheidungen sogar vor den Architekturentscheidungen getroffen und es besteht durchaus eine gegenseitige Beeinflussung von Fach- und Architekturentscheidungen. Ich rege daher an, strategische fachliche Entscheidungen ebenso zu behandeln, wie Architekturentscheidungen. In leicht angepasster Form können wir die fünf Fragenkomplexe wiederverwenden, die uns bei Architekturentscheidungen bereits gute Dienste erweisen. Während Architekturentscheidungen unter den Prämissen der Interessenvertretung und Kosteneffizienz getroffen werden, gelten für Fachentscheidungen die Prämissen des Kosten-Nutzen-Verhältnisses und der Wertmaximierung. Strategische Fachentscheidungen können in agilen Projekten Gültigkeit für mehrere User Stories haben und für die Ableitung weiterer Entscheidungen bei der Umsetzung der User Stories eine Orientierungshilfe bieten. Es ist auch denkbar, ausgewählte fachliche Entscheidungen aus der Produktvision heraus zu referenzieren.

Fragestellungen zur Dokumentation einer Fachentscheidung

Auch für Fachentscheidungen können Formulare und Listen verwendet werden, die weiter oben für Architekturentscheidungen bereits beispielhaft gezeigt wurden. Die Verwendung ist sowohl in Wasserfall-Projekten als auch in agilen Projekten möglich und kommt der Qualität und Kommunizierbarkeit fachlicher Entscheidungen meiner Meinung nach zugute.

Advertisements