Mit jedem neuen Softwareprojekt kommt auch immer wieder die Frage nach der dazu passenden Softwarearchitektur auf. In meinem Studium und zu Beginn meiner Karriere war ich immer auf der Suche nach der perfekten Softwarearchitektur. Zum Projektstart mögen meine initialen Architekturentscheidungen vielleicht noch ziemlich schlau gewesen sein, aber die sich im Laufe des Projekts ändernden Anforderungen haben selten Rücksicht auf meine zu Beginn getroffenen Architekturentscheidungen genommen. Die Konsequenz war, dass zum Projektende von der ursprünglichen Softwarearchitektur nur noch wenig übrig war (good case) oder die sich zu Beginn getroffenen Entscheidungen als Ballast (bad case) herausgestellt haben.
Walking on water and developing software from a specification are easy if both are frozen.
Edward V Berard
Damit komme ich auch zu dem eigentlichen Kernthema dieses Beitrags. Was zeichnet eine gute Softwarearchitektur aus und wie kann diese nachhaltig und sinnvoll dokumentiert werden?
Was ist eigentlich eine Softwarearchitektur?
Im letzten Absatz habe ich den Begriff Softwarearchitektur bereits sehr strapaziert. Hier folgt zunächst eine Definition:
Eine Softwarearchitektur ist eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie die Beschreibung ihrer Beziehungen.
Helmut Balzert
Wobei es nicht die eine Definition gibt, sondern eine Vielzahl an unterschiedlichen Definitionen, welche aus meiner Sicht oft eher technisch orientiert sind.
Am Anfang steht jedoch immer die Anforderung. Denn eine Architektur hat keinen Selbstzweck, sondern soll die Erstellung einer funktionierenden Software ermöglichen, welche die definierten und gewünschten Anforderungen des Auftraggebers erfüllt.
Eine Softwarearchitektur ist somit auch die Summe der Entscheidungen, die zu einem System führen, welches im besten Falle alle funktionalen und auch nicht funktionalen Anforderungen des Auftraggebers erfüllt.
Was zeichnet eine gute Softwarearchitektur aus?
Eine gute Softwarearchitektur ist die Summe aller Entscheidungen die zu einem Softwaresystem führen, welches alle funktionalen und nicht funktionalen Anforderungen der Auftraggeber erfüllt.
Jetzt kommen wir zum eigentlichen Problem, dass Anforderungen zu Beginn eines Softwareprojekts noch nicht vollständig bekannt sind oder sich zwangsläufig im Laufe eines Projekts verändern.
Diesem Umstand muss eine gute Softwarearchitektur Rechnung tragen. Einen Denkanstoß kann hierbei die nicht unumstrittene “Worse is better” Philosophie von Peter Gabriel aus dem Jahr 1989 liefern:
Regeln:
- Simplicity - Simplicity is the most important consideration in design
- Correctness - The design must be correct, but it is slightly better to be simple than correct.
- Consistency - Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.
- Completeness - The design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness must sacrificed whenever simplicity is jeopardized.
Kevin Henley geht in dem folgenden sehenswerten Video im Detail auf die Idee hinter der “Worse is better”-Philosophie ein. Er ist regelmäßiger Speaker auf der JAX und der OOP und seine Talks sind immer einen Besuch wert.
Wie kann mir arc42 bei der Beschreibung meiner Softwarearchitektur helfen?
Hinter arc42 verbirgt sich im wesentlichen ein Template zur Entwicklung, Dokumentation und Kommunikation von Softwarearchitekturen. Die Autoren sind Dr. Gernot Starke und Dr. Peter Hruschka.
Ein witziges Anwendungsbeispiel ist der arc42-Starschnitt von Stefan Zörner. In dem Starschnitt - wie Bravo-Starschnitt - wird ein Architektur-Überblick des Gradle-Buildsystems auf Basis von arc42 vorgestellt.
Meine Buchempfehlungen zu diesem Thema:
- Effektive Softwarearchitekturen: Ein praktischer Leitfaden von Gernot Starke
- Softwarearchitekturen dokumentieren und kommunizieren: Entwürfe, Entscheidungen und Lösungen nachvollziehbar und wirkungsvoll festhalten von Stefan Zörner
Die folgende Auflistung zeigt den grundlegenden Aufbau von arc42. Die Details zu den einzelnen Punkten sind im arc42 Wiki zu finden:
Aufbau arc42:
- Einführung und Ziele
- Randbedingungen
- Kontextabgrenzung
- Lösungstrategie
- Bausteinsicht
- Laufzeitsicht
- Verteilungssicht
- Konzepte
- Entwurfsentscheidungen
- Qualitätsszenarien
- Risiken
- Glossar
Jeder Punkt in der Auflistung hat seine Berechtigung. In einer idealen Welt sollte eine Architekturbeschreibung auch all diese Aspekte abdecken. Meine Erfahrung hat mir jedoch gezeigt, dass wir nicht in einer idealen Welt leben und Planung bzw. Dokumentation nicht immer die höchste Priorität genießt. Gemäß dem Motto:
Days of working will save you hours of planning.
unbekannt
Doch die Dokumentation der drei in der obigen Auflistung fett markierten Punkte ist immer - wirklich immer - eine gute Idee.
Die drei wichtigsten Aspekte bei der Beschreibung einer Softwarearchitektur
Ziele
Dass sich Anforderungen während eines Entwicklungsprojektes ändern, ist keine neue Erkenntnis und wurde von Edward Berard bereits 1993 kommentiert.
Die Dokumentation der initialen Anforderungen bzw. Ziele ist wichtig, aber die regelmäßige Überprüfung der Anforderungen und die Dokumentation eines Deltas ist genauso wichtig. Es soll schließlich sichergestellt werden, dass das Entwicklungsteam in die vom Auftraggeber gewünscht Richtung rennt, auch wenn sich die Richtung zwischendurch mal ändert.
Entwurfsentscheidungen
Alle getroffenen Entscheidungen, deren Rücknahme bzw. Veränderung signifikante Ressourcen (Zeit, Geld, …) kosten, sind Entscheidungen, deren Dokumentation sinnvoll ist. Während der Dokumentation sollte nochmals überprüft werden, ob diese Entscheidung wirklich zur Umsetzung einer Anforderung beiträgt. ;-)
In jedem Projekt kommt irgendwann mal die Frage nach dem Warum auf. Im schlimmsten Fall lautet die Frage: “Was für ein Quatsch! Warum haben Sie das denn gemacht?”
Wenn man in solchen Fällen als Softwarearchitekt ein Dokument mit einer sinnvollen Begründung aus der Tasche ziehen kann, schadet das sicherlich nicht.
Risiken
Die Dokumentation von Risiken und vor allem die technischen Schulden ist auch immer sehr sinnvoll.
In Projekten kommen immer wieder Phasen, in denen fachlicher Druck aufgebaut und auf schnelle Ergebnisse gedrängt wird. Geht man nach so einer Phase über die aufgebauten Schulden und Risiken hinweg, dann riskiert man schnell eine Überschuldung, um bei der Metapher zu bleiben.
Können Sie jedoch beim nächsten Lenkungsausschuss eine Liste mit Risiken/Konsequenzen vorlegen, dann liegt die Entscheidung über das weitere Vorgehen beim Auftraggeber. Die Wahrscheinlichkeit ist hoch, dass in solchen Fällen zunächst eine Konsolidierungsphase initiiert wird, um die aufgebaute Schuld zu reduzieren.
Fazit
In meinen Projekten war die Verwendung des arc42 Templates und die Konzentration auf die oben beschriebenen drei Punkte immer ein Erfolgsfaktor:
- Ziele
- Entwurfsentscheidungen
- Risiken
Die Dokumentation der Architektur ist das eine, die Kommunikation im Team das andere. Aus diesem Grund finde ich die Idee hinter der “Worse is better” Philosophie reizvoll. Steht man vor der Herausforderung, regelmäßig neue Menschen in ein Projekt zu integrieren oder größere Teams zu managen, dann ist die Konzentration auf “Simplicity” ein hilfreicher Ansatz.
Es soll einfach sein – aber genial einfach, nicht dumm einfach!
Gunter Dueck