Warum Softwarearchitektur wichtig ist

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 Beschreibungen dreht sich dabei im wesentlichen um Funktionalitäten einer Anwendung und damit um offensichtliche Eigenschaften.

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 ihrere 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 9126 zusammgenfasst (welche inzwischen von der ISO/IEC 25000 abgelöst wurde).

Softwarequalitätsmerkmale nach ISO 9126
Softwarequalitätsmerkmale nach ISO 9126

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 Kofigurationen 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 gegegeben 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.

Gliederung von arc42
Gliederung von arc42

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).

Robert K√°roly Verfasst von:

Schreibe den ersten Kommentar

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.