Architekturentscheidungen dokumentieren

Entscheidungen treffen

Warum um Himmels Willen haben wir das damals so entschieden? Wer hat sich nicht schon einmal während der Entwicklung gefragt, auf welcher Basis eine Architekturentscheidung gefallen ist? Bei der Entwicklung von komplexen Systemen sind immer wieder Entscheidungen zu treffen. Wichtige Architektur- oder Designentscheidungen sollten immer dokumentiert werden. Doch wie geht man dabei am besten vor? Dieser kleine Leitfaden soll bei der Dokumentation von Architekturentscheidungen behilflich sein.

Wie geht man vor?

Es bietet sich an ein festes Schema zu verwenden. Ich habe dieses Schema in der Abbildung unten als Ablaufdiagramm dargestellt.

Fragestellung und Problembeschreibung

Bevor man eine Entscheidung treffen kann, muss man im ersten Schritt die Fragestellung oder Problembeschreibung sauber definieren. Nur auf eine gute Frage, kann man auch eine entsprechende Antwort geben. Es lohnt sich daher, sich zu Beginn mit Fragestellung oder Problembeschreibung auseinander zu setzen. Das hat auch einen sehr guten Nebeneffekt. Andere Projektbeteiligte (Kunden, Entwickler, Projektleiter, Systemarchitekten) können einschreiten, wenn die falsche Frage beantwortet werden soll. Ich habe bereits oft erlebt, dass die Fragestellung nicht klar war. Bei einer missverständlichen Fragestellung kann eine ungünstige Entscheidung getroffen werden.

Auswirkung

Wer Entscheidungen trifft, muss mit den Auswirkungen leben können. Wird z.B. ein helleres Display mit besserer Auflösung verwendet, so kann sich das auf die Herstellkosten und den Stromverbrauch auswirken. Eine Entscheidung kann nur getroffen werden, wenn man die Auswirkungen kennt und akzeptiert.

Einflussbedingungen und Randbedingungen

In der Realität gibt es Randbedingungen und Einflussbedingungen, die die Anzahl an Lösungsmöglichkeiten einschränken. Die Randbedingungen müssen bei der Entscheidungsfindung berücksichtigt werden. So darf, z.B. das Volumen eines Gerätes nicht größer als ein Liter sein. Diese Randbedingung muss dann in der Architekturentscheidung Berücksichtigung finden.

Annahmen und Risiken

Wenn man doch immer wüsste, was eine Entscheidung für Folgen haben kann. Das geht leider nicht immer. Aber was man machen kann, ist sich über die Risiken bewusst zu werden und die Annahmen festzuhalten. Daher sollte man angeben, welche Annahmen für die Entscheidungsfindung vorausgesetzt und welche Risiken identifiziert wurden.

Alternativen betrachten und bewerten

Idealerweise gibt es verschiedene alternative konkurrierende Lösungen. Mithilfe einer Entscheidungsmatrix kann man die Alternativen gegenüberstellen und nach festgelegten objektiven Kriterien bewerten. Auf diese Weise kommt man zu objektiven Entscheidungen, die für alle nachvollziehbar sind.

Entscheidung und Begründung dokumentieren

Schließlich hat man das Ziel erreicht. Die Entscheidung ist getroffen. Dann sollte man diese Entscheidung festhalten und insbesondere auch die Begründung, warum man sich dafür entschieden hat. Hier kann man sich z.B. auf die Entscheidungsmatrix stützen.

Was bringt das?

Durch die strukturierte Vorgehensweise trifft man aus meiner Erfahrung bessere Architekturentscheidungen. Es geht bei dem hier beschriebenen Vorgehen nicht nur darum die Entscheidung zu dokumentieren, sondern auch darum einen guten Entscheidungsfindungsprozess anzuwenden. Erst wenn man sich mit den oben beschriebenen Schritten beschäftigt hat, kann man eine gute Entscheidung treffen. Andere Projekt-Teilnehmer können die Entscheidung nachvollziehen und mittragen oder rechtzeitig ihre Bedenken äußern. Die Entscheidungsfindung wird transparent gemacht und ist auch noch Jahre später nachvollziehbar.

In welchem Format soll das geschehen?

Entscheidungen sollten niemals in Emails, im Laborbuch oder auf dem Whiteboard dokumentiert werden. Es bietet sich an für Architekturentscheidungen Konzept-Dokumente zu verwenden, deren Kapitelstruktur an der hier vorgeschlagenen Vorgehensweise angelehnt ist. In so einem Dokument hat man den Raum, der für die Entscheidungsfindung notwendig ist. In der Systemarchitektur oder in Designdokumenten kann man auf die Konzept-Dokumente verweisen. Ich würde die Entscheidungen nicht vollständig in der Systemarchitektur dokumentieren, um das Dokument nicht zu überladen. Die Systemarchitektur sollte aus meiner Sicht nur die Realisierung beschreiben und nicht alle untersuchten Möglichkeiten. Falls Sie ALM-Werkzeuge verwenden (wie z.B. Polarion), so bieten diese auch die Möglichkeit Kommentare zu bestimmten Workitems (Anforderungen, Architekturelementen) zu hinterlegen. Diese Funktionalität ist sehr praktisch, um Wissen zu dokumentieren, ohne damit formale Dokumente zu verändern.

Ich freue mich sehr über Feedback und den Austausch mit ihnen. Sie können gerne einen Kommentar zu dem Artikel abgeben. Falls sie jemanden kennen, für den der Blog ebenfalls interessant sein könnte, freue ich mich sehr über eine Weiterempfehlung.

Viele Grüße
Goran Madzar

Auch interessant:

Veranstaltungstipps 2017

Es gibt wieder jede Menge lohnenswerte Veranstaltungen auf die ich gerne hinweisen möchte. Alle werde ich leider aus Zeitgründen nicht besuchen können. Details entnehmen Sie bitte direkt auf den Webseiten…

Goran Madzar

Seit Mai 2007 bin ich zusammen mit meinem Kollegen Martin Bosch selbständig. Wir haben ein Ingenieurbüro im Innovations- und Gründerzentrum in Erlangen aufgebaut. Hier entwickeln wir für Kunden in der Medizintechnik mit unseren Mitarbeitern Lösungen für die Produkte von Morgen.

Getagged mit: , , , ,

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.