Wenn man eine App oder ein Programm beschrieben bekommt, richtet sich der Fokus in der Regel darauf, was die Anwendung alles kann. So gibt es Programme zum Texte schreiben, Fotos teilen, Steuererklärung machen, zur Bildbearbeitung oder einfach nur um mit Menschen auf der ganzen Welt zu kommunizieren, um nur einige Anwendungsfälle zu nennen. Die Beschreibung dreht sich dabei im wesentlichen um die Funktionalitäten einer Anwendung und damit um offensichtliche Eigenschaften bzw. den offensichtlichen Zweck.

Häufig werden Funktionalitäten als User Stories nach der Formel „Als <Rolle> möchte ich <Ziel/Wunsch> um <Nutzen>“ beschrieben. Ein Beispiel für einen Webshop könnte heißen: „Als <Kunde> möchte ich <den Status meiner Bestellungen sehen können>, um <zu sehen wann meine Bestellungen bei mir eintreffen>“. Es ist beschrieben Wer (Rolle), was genau tun kann (Feature) und was er er/sie davon hat (Mehrwert). Die Liste der Features bilden in ihrer Gesamtheit die funktionalen Anforderungen einer Software. Sind sie umgesetzt, sollte die User Story einen Satz ergeben, der wahr ist für diese Software.

Softwarequalität

Die funktionalen Eigenschaften einer Software sind jedoch nur eine Seite der Medaille, wenn auch die offensichtlichere. Daneben gibt es noch die nichtfunktionalen Eigenschaften einer Software. Dazu gehören die Qualitätsmerkmale welche zu meist unter der Haube stecken, wie z.B. Zuverlässigkeit, Fehlertoleranz, Performanz, Gebrauchstauglichkeit oder Sicherheit. Diese Qualitätsmerkmale sind in der ISO/IEC 25000 zusammengefasst.

Betrachtet man die Liste der Qualitätsmerkmale, merkt man schnell, dass es nicht nur viele Aspekte neben der reinen Funktionalität zu bedenken gibt, sondern auch, dass sich daraus weniger offensichtliche Stakeholder ableiten lassen. So ist es z.B. für die Entwickler einer Software in der Regel wichtig, dass diese leicht änder- und erweiterbar ist.

Betreiber wiederum werden sich dafür interessieren, ob die Anwendung leicht in Betrieb zu nehmen ist und das alle wesentlichen Konfigurationen dafür von ihnen selbst gemacht werden können, wenn z.B. die Software in einem anderen Rechenzentrum in Betrieb genommen werden soll. Wie sieht es mit der Kommunikation aus, wie mit der Ausfallsicherheit? Was passiert, wenn das System nicht mehr reagiert? Können durch einen Neustart Daten verloren gehen? Welche Hardware wird für den Betrieb benötigt? Mit welchen weiteren Systemen muss die Software kommunizieren können? Fragen über Fragen.

Auch der Gesetzgeber kann Anforderungen an ein System haben, wenn es z.B. um Datenschutz geht. Wo werden die Daten gespeichert? Sind sie verschlüsselt? Können aus einzelnen Teildaten Rückschlüsse auf die Personen gezogen werden, auf die sie sich beziehen? Die Gesetze wiederum können je nach Staat variieren und sich ändern. Kann die Software das in so einem Fall auch tun?

Abwägungen sind unvermeidbar

Sickert man den Morast all der Fragen ab, die sich da ergeben können wird schnell klar, dass man sich beliebig lange und intensiv damit befassen kann seine Software auf diese Qualitätsmerkmale hin zu optimieren. Dabei ist dann mitunter kein einziges Feature entstanden, dass einem konkreten Endnutzer einen Mehrwert bietet. Auf der anderen Seite können gewaltige Entwicklungskosten stehen. Am Ende muss man irgendwie auch noch sicher stellen, dass diese Eigenschaften alle erhalten bleiben und dies mit Tests absichern.

Schlimmer noch: Einige der Qualitätseigenschaften sind natürliche Gegenspieler. So ist es zum Beispiel häufig bei Performanz und Sicherheit der Fall: Möchte man wirklich den Benutzer nach dem Speichern vor einem Forumular warten lassen, bis die Datenbank via Server mit verschlüsselter Verbindung bestätigt hat, dass die eingegebenen Daten gültig sind, anderen Angaben nicht widersprechen und sicher abgespeichert wurden?

Man muss also ein Stück weit abwägen, was für die jeweilige Software wichtiger ist. Spätestens jetzt braucht es Entscheidungen.

Architektur Entscheidungen

Architektur Entscheidungen sind im Grunde genommen alle Entscheidungen, die im Laufe der Entwicklung einer Software getroffen werden, welche später nur aufwändig (= teuer) änder- oder revidierbar sind.

Damit wird schnell klar, dass im wesentlichen jeder Entwickler einer Software, als auch jeder andere Stakeholder, welcher Entscheidungen über die Qualitätsmerkmale (und damit die „Ziele“) trifft zum Softwarearchitekten.

Da Entscheidungen größerer Tragweite sollten im Team besprochen und gemeinsam getroffen werden. Zum einen auf Grund der Transparenz, zum anderen auch, damit alle Bedenken gehört und besprochen werden können. Softwarearchitektur ist ein Teamspiel. Schon alleine weil alle Beteiligten die Entscheidung am Ende mit tragen müssen. Damit haben im Umkehrschluss alle, die von der Entscheidung nicht betroffen sind, in der Diskussion nichts verloren.

Entscheidungen dokumentieren

Im Anschluss sollte die Entscheidung dokumentiert werden. Dabei sollte festgehalten werden wer, wann welche Entscheidung warum getroffen hat, welche Gründe es dafür gab, welche dagegen sprachen als auch ggf. welche Alternativen es gegeben hätte.

Da man manchmal, um Aufwand zu sparen oder weil man einfach von anderen Abhängig ist, nicht die augenscheinlich richtige Entscheidung treffen kann, ist es wichtig die Umstände festzuhalten. So können Entscheidungen im Nachgang z.B. geändert werden, wenn der Blocker wegfällt, wegen dem man den weniger guten Weg wählen musste.

Hält man das nicht fest und keiner erinnert sich mehr genau an die Situation zur gegebenen Zeit, wird man sich später vielleicht fragen warum etwas so „offensichtlich falsch“ gemacht wurde. Da es aber zu vorsätzlich wirkt, wird man immer zu viel Respekt davor haben es zu ändern.

Eine Möglichkeit Architektur Entscheidungen zu dokumentieren bieten Archictecture Decision Records (ADR), die auf eine Idee von Michael Nygard zurückgehen.

Softwarearchitektur

Eine Dokumentation der funktionalen und nichtfunktionalen Merkmale eines Systems bezeichnet man als Softwarearchitektur. Diese sollte neben den wesentlichen verschiedenen Sichten für Unterschiedliche Stakeholder, auch die wesentlichen Architektur Entscheidungen enthalten.

Ein bekanntes, freies Template um Softwarearchitekturen zu beschreiben, mit dem ich gute Erfahrungen gemacht habe, ist arc42. Der wichtigste Vorteil eines solchen Templates ist sicher, dass sich konkrete Informationen zur Architektur einer Software immer an der selben Stelle befinden. Man weiß also, wo man nach danach suchen muss, wenn man die Struktur mal kennt. Steht an der Stelle die Information nicht, so gibt es diese bisher nicht oder entsprechende Entscheidungen wurde noch nicht getroffen.

Nebenbei hilft einem die Struktur auch wesentliche Aspekte einer Software bewusst zu beschreiben, sodass sowohl aussenstehende, als z.B. auch neue Entwickler sich schnell mit dem Code zurecht finden. Desweiteren fördert eine konsequente Benennung an dieser Stelle die Kommunikation aller Stakeholder, da sich bestimmte Begriffe für bestimmte Prozesse, Module usw einfach festigen und damit auch Missverständnissen vorbeugen.

Ein Wort der Warnung sei hier jedoch angebracht: Bitte nicht das Template verwenden, um es up-front mit allem was es so gibt auszufüllen. Es ist kein Fragebogen. Das ist nicht nur unagil, es führt auch dazu das ggf. Entscheidungen getroffen werden, die an der Stelle noch gar nicht getroffen werden müssen und zu einem späteren Zeitpunkt qualifizierter getroffen werden können. Eine Architektur ist ein lebendes Dokument in welches alles einfließen sollte, was wirklich wichtig ist.

Die richtigen Fragen stellen

Womit wir zum Schluss kommen. Bei der Softwarearchitektur geht es nicht nur darum Entscheidungen bzgl. der funktionalen und nichtfunktionalen Anforderungen zu treffen, zu Priorisieren und die Ergebnisse zu dokumentieren. Es geht vielmehr darum die richtigen Fragen zu stellen, um bewusst die wichtigen Entscheidungen zu treffen welche sich am Ende maßgeblich auf den Produkterfolg auswirken können. Aus agiler Sicht geht es auch darum bewusst abzuwägen was überhaupt so wichtig ist, dass darauf ein Fokus gelegt werden soll. Für diese Merkmale können dann Kriterien festgelegt werden, um das geforderte Qualitätsmaß als Anforderung zu beschreiben. Diese kann dann messbar und damit testbar gemacht werden. Auf der anderen Seite braucht man sich nicht mit Qualitätsmerkmalen befassen, welche für die Software ohnehin keine oder nur eine geringe Rolle spielen. Aus Sicht der Effizienz ist es gut die Arbeit, die nicht getan werden muss zu maximieren. Aus Sicht der Effektivität ist es gut, wenn die wesentlichen Ziele mit Hilfe messbarer Kriterien erreicht wurde.

Templates wie arc42 helfen wiederum dabei, die richtigen Fragen zu stellen und die wesentlichen Entscheidungen zu treffen. Dazu kommt, dass Sie als Mittel der Kommunikation sehr dienlich sind, indem gemeinsame Begrifflichkeiten gefestigt werden und Produktfremden schnell einen Überblick über die wesentlichen Eigenschaften der Software gewährt wird.

tl;dr

Softwarearchitektur hilft wesentliche Qualitätsmerkmale einer Software zu planen, in dem sie hilft die richtigen Fragen zu stellen, Entscheidungen zu treffen und diese nachzuhalten. Als lebendes Dokument nützt sie dabei allen Beteiligten mit jeweils eigenen Sichten und bietet Zugriff auf alle wesentlichen Informationen an einer zentralen Stelle auf Basis einer übertragbaren Struktur (z.B. arc42).