Software-Architektur: Worauf es ankommt

Grundlagen für Software-Architektur

Die Architektur definiert die Struktur eines Software-Systems und ist zentral für den Erfolg eines Projekts. Deswegen ist Software-Architektur so wichtig. Aber in Wirklichkeit ist Software-Architektur noch viel mehr und eine erfolgreiche Software-Architektur erfordert viele, teilweise überraschenden Maßnahmen.

Wenn man die wesentlichen Aspekte von Software-Architektur beschreiben soll, muss man zunächst den Begriff „Software-Architektur“ selber klären. Wikipedia und der Standard ISO/IEC 42010 definieren Software-Architektur als die grobgranulare Strukturierung eines Software-Systems. Dazu passt der Begriff „Architektur“: Die Architektur eines Gebäudes gibt die groben Strukturen vor. Die meisten Architektur-Entwürfe zeigen dementsprechend die Aufteilung des Systems in größere Komponenten.

Ein Gedankenexperiment zeigt, ob diese Definition ausreichend ist: Eine Software geht nicht in Produktion. Es ist ein Sicherheitsproblem entdeckt worden und ein Problem mit der Compliance. Einen solchen Fehlschlag kann man wohl kaum als erfolgreiche Architektur bezeichnen. Aber das Sicherheitsproblem ist wahrscheinlich nicht auf der Ebene der Strukturierung des Systems zu erkennen. Es kann ein einfacher Programmierfehler oder eine unsichere Technologie sein, die zu dem Problem geführt hat. Also muss Software-Architektur etwas anderes umfassen als nur die Struktur des Systems, denn offensichtlich können auch andere Faktoren zu einem Architektur-Fehlschlag führen.

Martin Fowler als anerkannter Experte sieht Software-Architektur als die Menge aller wichtigen und schwer änderbaren Entscheidungen [1]. Das passt besser zu dem Gedanken-Experiment: Offensichtlich waren die Entscheidungen im Sicherheitsbereich wichtig, denn sie haben verhindert, dass das System in Produktion geht. Und sie sind nicht einfach zu ändern, sonst wäre das Problem schnell und einfach gelöst werden. Also ist die Definition eigentlich ganz gut. Genau genommen kann man vorab nicht wissen, welche Entscheidungen schwer zu ändern sind. Wie schwierig das ist, findet man nur sicher heraus, wenn man die Entscheidung tatsächlich revidiert.

Eine andere Möglichkeit, Software-Architektur zu definieren ist relativ schlicht: Software-Architektur bedeutet, dass man eine technische Software-Lösung für das jeweilige Problem entwirft. Diese Definition ist nicht sonderlich spezifisch. Sie passt zu allen Arten von technischen Ingenieursdisziplinen. Aber die Definition zeigt wie wichtig es ist, das Problem zu kennen, das gelöst werden muss.

Der Hinweis auf das zu lösende Problem mag trivial erscheinen. Allerdings enthalten Architektur-Dokumentationen zwar fast immer eine Darstellung der grobgranularen Struktur des Systems aber fast nie Informationen dazu, welches Problem das System eigentlich überhaupt lösen soll. So ist es schwierig, die konkreten Entscheidungen nachzuvollziehen oder zu bewerten.

Qualitätsbaum

Für die Darstellung einer Architektur haben sich mittlerweile viele unterschiedliche Wege etabliert und werden auch breit genutzt. Es gibt auch Werkzeuge, um das Problem besser zu verstehen und darzustellen. Die sind aber bei weitem nicht so bekannt. ISO 25010 definiert dafür den Qualitätsbaum. Auch Standards für Architektur-Dokumentation wie arc42 [2] beinhalten diese Aspekte.

Ausschnitt aus dem Qualitätsbaum (Abb. 1)
Ausschnitt aus dem Qualitätsbaum (Abb. 1)

Abbildung 1 zeigt einen Ausschnitt aus dem Qualitätsbaum. In dem Qualitätsbaum sind verschiedene Qualitätsmerkmale wie Sicherheit oder Zuverlässigkeit aufgelistet.

Für jedes Qualitätsmerkmal gibt es eine Liste von Teilmerkmalen. Die Teilmerkmale machen es einfacher, ein Qualitätsmerkmal wirklich vollständig zu betrachten. Bei Zuverlässigkeit geht die Diskussion oft schnell in die Richtung der Verfügbarkeit. Ein Blick in den Qualitätsbaum zeigt weitere Teilmerkmale wie Fehlertoleranz. Fehlertoleranz bedeutet, dass ein System trotz des Ausfalls einiger Komponenten weiter funktionieren muss. Ein weiteres Teilmerkmal ist die Wiederherstellbarkeit: Es kann wichtig sein, dass ein System nach kurzer Zeit wieder zur Verfügung steht.

Bei Sicherheit in der Abbildung ist nur ein beispielhaftes Teilmerkmal aufgelistet: Die Nachweisbarkeit. Es kann sein, dass Benutzerinterkationen beispielsweise vor Gericht nachgewiesen werden müssen.

Durch den Qualitätsbaum wird offensichtlich, welche Merkmale Software überhaupt erfüllen kann. Architekten können mit dem Qualitätsbaum überprüfen, ob wirklich alle wesentlichen Qualitätsmerkmale der Software betrachtet worden sind.

Qualitätsszenarien

Dennoch reicht der Qualitätsbaum nicht aus: Die Einhaltung der Qualitätsmerkmale können nur schlecht verifiziert werden. Doch auch dafür gibt es ein geeignetes Software-Architektur-Werkzeug: Das Qualitätsszenario (siehe Abbildung 2).

Qualitätsszenarien (Abb. 2)
Qualitätsszenarien (Abb. 2)

Ein Qualitätsszenario beschreibt ein Ereignis, das auf das System einwirkt, und eine Metrik, um das gewünschte Verhalten des Systems zu definieren. Ein Qualitätsszenario ist konkret und leicht zu verifizieren, weil es eine Metrik festlegt.

Es gibt verschiedene Arten von Szenarien:

Bei Benutzungsszenarien geht es um Anforderungen, die sich aus der Benutzung ergeben. Ein Beispiel: „Wenn sich ein Benutzer registriert, soll nur einer von 1.000 Benutzern die Hotline anrufen.“ Das Ereignis ist die Registrierung. Die Metrik ist die Anzahl der Anrufe bei der Hotline. Das Szenario beschreibt das Qualitätsmerkmal der Benutzbarkeit. Durch die Metrik ist sichergestellt, was mit einem „einfach zu benutzenden System“ gemeint ist. Um dieses Qualitätsszenario zu erfüllen, kann man beispielsweise UX-Experten zum Projekt hinzuziehen oder Benutzer-Tests einplanen. Solche Maßnahmen gehören nicht zur klassischen Architektur-Arbeit, sind aber die richtigen Maßnahmen, um das Projektziel zu erreichen.

Ein Änderungsszenario beschreibt, wie ein System auf eine Änderung reagieren soll. Ein Beispiel: „Wenn eine neue Sprache oder ein neues Land unterstützt werden soll, darf dazu keine Änderung am Code notwendig sein. Die Änderung muss mit einem Aufwand von höchstens zwei Personentagen umgesetzt werden können.“ Dieses Szenario gehört zum Qualitätsmerkmal der Änderbarkeit. Die Lösung ist offensichtlich: Es muss eine Konfiguration mit den entsprechenden Texten und weiteren Einstellungen für die verschiedenen Länder geben.

Schließlich gibt es Ausfallszenarien. „Wenn ein Server ausfällt, dann muss das System spätestens nach zwei Stunden wieder zur Verfügung stehen. Es dürfen keine Daten verloren gehen.“ Hier geht es um das Qualitätsmerkmal „Zuverlässigkeit“ und genauer gesagt um die Fehlertoleranz. Um die Anforderungen zu erfüllen, könnte ein redundantes Speicher-System oder ein Backup ausreichen. Ein Cluster wäre zwar auch als Lösung denkbar, aber wegen der recht langen Zeit, in der das System nicht verfügbar sein darf, ist ein Cluster nicht zwingend notwendig.

Die Qualitätsszenarien zeigen klar, was das System leisten muss, um die Anforderungen zu erfüllen. Idealerweise sollte die Architektur nicht nur Qualitätsszenarien auflisten, sondern auch Lösungen aufzeigen, um die Qualitätsszenarien zu erfüllen. Das ist leider die absolute Ausnahme bei typischen Architektur-Beschreibungen. So kann aber nicht garantiert werden, dass die entwickelten Systeme die Probleme überhaupt lösen.

Oft wird eine „gute“ Architektur mit hoher Codequalität, einer sauberen Struktur oder guter Skalierbarkeit gleichgesetzt. Aber keine dieser Eigenschaften hätte auch nur ansatzweise dabei geholfen, irgendeines der oben genannten Qualitätsszenarien zu erfüllen. Ebenso ist die Benutzung bestimmter Frameworks oder Programmiersprachen völlig unerheblich dafür, ob diese Qualitätsszenarien erfüllt werden oder nicht. Mit anderen Worten: Wenn man wirklich eine Lösung für die Anforderungen im Projekt entwickeln will, ist die traditionelle Architektur-Arbeit höchstens ein Teil der Lösung und oft noch nicht einmal der wichtigste.

Rollen

Ein weiterer Aspekt, der bei der Architekturarbeit oft unterschätzt wird, sind die Rolle und das Selbstverständnis der Software-Architekten. Obwohl dieser Aspekt so ein Schattendasein führt, ist er dennoch sehr wichtig.

Traditionell ist „Software Architekt“ ein Titel und oft auch eine Stufe auf der Karriereleiter. Die moderne Interpretation von „Software Architekt“ ist anders: Es ist die Person, die Architektur macht. Und es ist eine Rolle: Zu unterschiedlichen Zeiten können unterschiedliche Personen die Rolle „Software Architekt“ haben. Diese Personen können den Titel „Software Architekt“ haben oder auch nicht. Wenn man die oben erwähnten Qualitätsszenarien betrachtet, deren Erfüllung zur Architektur gehört, dann können klassische Architekten nur wenige dieser Qualitätsszenarien erfüllen.

Oft haben traditionelle Software-Architekten an sich die Anforderung, die bezüglich Technologien erfahrensten Personen im Team zu sein. Schließlich treffen Architekten Entscheidungen, die weitreichende Konsequenzen haben. Zweifellos müssen sie daher die beste Qualifikation mitbringen. Wenn jemand an sich die Anforderung stellt, für jedes Detail und jede Technologie die erfahrenste Person im Projekt zu sein, dann ist das schlicht unrealistisch. Kommt noch der Anspruch dazu, alle wichtigen Entscheidungen zu fällen, dann setzen sich Software Architekten selbst gewaltig unter Druck. Es ist unklar, warum Architekten freiwillig solche Rollen spielen wollen. Aber eigentlich ist schon der Anspruch, dass der Architekt die mit allen Technologien erfahrenste Person im Team sein soll, ziemlich traurig. In einem solchen Team hätte der Architekt niemanden, von dem man lernen kann.

Die moderne Interpretation der Rolle „Software Architekt“ geht anders mit den technischen Skills um. Der Architekt soll die Expertise des gesamten Teams nutzen. Um das Team noch erfolgreicher zu machen, soll er dafür sorgen, dass sich die Team-Mitglieder weiterentwickeln und neue Fähigkeiten erlernen.

Es gibt nicht nur Unterschiede bei der Interaktion im Team, sondern auch bei den konkreten Tätigkeiten. Der traditionelle Architekt ist dafür verantwortlich, das gesamte System zu verstehen. Das ist aber kaum möglich: Software-Entwicklung ist vor allem eine Herausforderung, weil bis auf wenige Ausnahmen Systeme entwickelt werden, die so groß sind, dass eine einzelne Person sie nicht entwickeln und auch nicht vollständig verstehen kann. Also kann auch ein Software Architekt das System nicht vollständig detailliert verstehen. Er muss auch für das Verständnis des Systems auf die Expertise des Teams zurückzugreifen. Jeder Mitarbeiter im Team kennt einen bestimmten Teil und Aspekt des Systems. Es ist die Aufgabe des Architekten, diese Expertise zu nutzen und auf dieser Basis das System gemeinsam mit dem Team weiterzuentwickeln.

Architektur durchsetzen?

Der klassische Architekt würde eine Architektur definieren, alle relevanten Entscheidungen treffen und dann diese Architektur im Projekt durchsetzen. Dazu muss der Architekt eine Rolle im Projekt haben, die das Durchsetzen der Architektur ermöglicht. Oft werden Projekt agil nach Scrum entwickelt. Scrum kennt die Rolle des Product Owner. Diese Person definiert die zu implementierenden Features als Stories. Das Team implementiert diese Stories und organisiert sich dabei selbst. Der Scrum Master beseitig Hindernisse und sorgt dafür, dass die Scrum-Regeln eingehalten werden.

In der Scrum-Organisation kann der Architekt „nur“ ein einfaches Team-Mitglied sein. Dann kann der Architekt aber die Architektur nicht durchsetzen. Schließlich ist das Team selbst organisiert und daher entscheidet das Team als Ganzes, wie es arbeiten will. Wenn diese Regel nicht eingehalten wird, sollte der Scrum Master einschreiten, denn dann wird eine wesentliche Scrum-Regel verletzt.

Also kann der Architekt die Architektur in einem agilen Projekt gar nicht durchsetzen. Aber selbst wenn der Architekt die Architektur durchsetzen dürfte, bleibt die Frage offen, wie er zum Durchsetzen der Architektur konkret vorgehen soll. Da der Architekt nicht wissen kann, was alles im Projekt vorgeht, ist es schwierig, die Architektur durchzusetzen. Es kann passieren, dass das Team die Architektur gar nicht umsetzt, aber der Architekt das nicht merkt, weil er eben nicht das gesamte System verstehen kann.

Der Elfenbeinturm-Effekt

So kommt es leicht zu dem Elfenbeinturm-Effekt: Der Architekt versteht die Herausforderungen des Systems nicht, weil er das System nicht vollständig verstehen kann und mit den anderen Team-Mitgliedern nicht ausreichend kommuniziert. Auf Basis dieser falschen Informationen trifft er Architektur-Entscheidungen, die gegebenenfalls nicht umgesetzt werden, weil sie keine realen Probleme lösen. Das wiederum merkt der Architekt nicht, weil er eben nicht das gesamte System verstehen kann. So lebt er von der Realität entkoppelt in einem Elfenbeinturm: Er kennt das System eigentlich nicht und seine Tätigkeit hat auch keine Auswirkung auf das Projekt.

Eine moderne Interpretation der Rolle „System Architekt“ setzte auf die Kollaboration im Team, um die gesamte Expertise des Teams zu nutzen und so bessere Architekturen zu erarbeiten. Entscheidungen, an denen das gesamte Team intensiv mitgearbeitet hat, haben außerdem eine höhere Wahrscheinlichkeit, tatsächlich umgesetzt zu werden. Schließlich haben sich alle an dem Thema beteiligt. Daher gibt es kaum einen Grund, die gemeinsame Entscheidung nicht auch gemeinsam umzusetzen. So vermeidet dieses Vorgehen den Elfenbeinturm-Effekt.

Die Rolle „Software Architekt“ ist eher die Rolle eines Moderators, der die Entscheidungsprozesse unterstützt. Dabei macht er seine technische Expertise nutzbar und bringt sich daher auch inhaltlich in die Diskussion ein. Aber im Mittelpunkt steht die Zusammenarbeit.

Software Architektur: Ein kollaboratives Spiel

Software Architektur erinnert damit an kollaborative Spiele wie Pandemie [3]. Im Gegensatz zu anderen Spielen gewinnen bei einem kollaborativen Spiel alle gemeinsam oder sie verlieren gemeinsam. Das ist bei einem Software-Projekt nicht anders: Wenn das Projekt nicht erfolgreich ist, verlieren alle dabei. Bei Pandemie geht es darum, den Ausbruch einer Pandemie zu vermeiden. Die Figur jedes Spielers hat dabei bestimmte Stärken: Der Arzt kann Infizierte besser heilen und der Logistiker andere Figuren einfacher durch die Welt reisen lassen. Diese Stärken können kombiniert werden, um so besondere Vorteile zu erreichen. So kann der Logistiker den Arzt dahin schicken, wo gerade besonders viele Infizierte sind. Diese besten Synergien herauszufinden und ein gemeinsames Handeln zu planen und umzusetzen, sind der Kern des Spiels. Das bedeutet, dass alle Beteiligten dauernd miteinander reden, um das gemeinsame Vorgehen abzusprechen. So sind alle Spieler ständig involviert – auch wenn gerade jemand anders am Zug ist. Spezielle Fähigkeiten und spezielles Wissen zeichnen auch die Teammitglieder in einem Software-Projekt aus. Und auch in einem Software-Projekt ist Kommunikation der Schlüssel, um das Projekt erfolgreich umzusetzen.

Entscheidungen

Konkret geht es bei der Architektur-Arbeit meistens darum, Entscheidungen zu treffen. Es müssen Lösungen für die aktuellen Herausforderungen gefunden werden. Dabei gibt es oft mehrere Optionen und eine der Optionen muss ausgewählt werden. Allerdings sind die Informationen über das System und über das zu lösende Problem meistens nicht vollständig. Dass nie alle Informationen vorliegen, ist eine grundlegende Herausforderung bei der Software-Entwicklung. Das gilt vor allem für die Anforderungen. Dennoch muss das Team Entscheidungen treffen. Und es kann schwierig und teuer sein, weitere Informationen zu bekommen. Selbst wenn es möglich ist, mehr Informationen zu bekommen, kann es dauern, bis die Informationen tatsächlich vorliegen und dann kann es auch schon zu spät sein.

Also muss man sich daran gewöhnen, ständig Entscheidungen mit zu wenig Informationen zu treffen. Das setzt Mut voraus. Es gibt dennoch eine Optimierungsmöglichkeit: Wenn man eine Entscheidung später trifft, dann gibt es mehr Informationen, weil man in der Zwischenzeit mehr Erkenntnisse gesammelt haben wird. Außerdem: Wenn man Entscheidungen zu früh fällt, kann es gut sein, dass man Entscheidungen über Dinge trifft, die erst sehr viel später relevant werden oder vielleicht sogar nie, weil doch andere Dinge als gedacht implementiert werden. Also sollte man sich vor jeder Entscheidung fragen, ob man sie jetzt fällen muss und was passiert, wenn man die Entscheidung später oder sogar zu spät trifft.

Ein konkretes Beispiel: Ein Startup entwirft ein IT-System. Das System soll natürlich Rechnungen erstellen können, denn sonst gibt es keinen Umsatz. Offensichtlich ist das Erstellen der Rechnungen ein wichtiges Feature und man muss eine Architektur dafür definieren. Aber um Umsatz zu generieren, muss es erst Kunden geben. Wer schon selbstständig war, kennt das manuelle Schreiben von Rechnungen. Man kann also durchaus auch Rechnungen ohne Automatisierung erstellen. Außerdem hat dieses IT-System ein Abo-Modell, das am Monatsende abgerechnet wird. Wenn die ersten Kunden da sind, hat man also noch einen Monat Zeit, das Schreiben der Rechnungen zu implementieren. Also kann man die Arbeit an diesem Teil der Architektur erstmal zurückstellen. Wenn man tatsächlich mit der Architektur für die Erstellung der Rechnungen beginnt, hat man auf jeden Fall mehr Informationen und kann so zu einer besseren Architektur kommen. Die besten Entscheidungen sind also die, die man noch nicht getroffen hat.

Aus der Unsicherheit bei dem Treffen der Entscheidungen kann man ableiten, dass man sicher suboptimale Entscheidungen treffen wird. Wenn man nun aber noch mehr Aufwand investiert, um bessere Entscheidungen zu treffen, wird das nicht viel helfen. Die Unsicherheiten lassen sich nicht wirklich auflösen. Also sollte man sich eher darauf einstellen, dass man Entscheidungen wird revidieren müssen. Wenn man nicht auf neue Informationen reagiert, wird die Architektur darunter leiden. Die Erklärung für die meisten Architektur-Probleme ist nicht, dass sich die Architekten nicht genug angestrengt haben. Die Erklärung ist, dass es neue Erkenntnisse gab, die nicht in die Architektur eingeflossen sind, weil die Architektur nicht revidiert worden ist.

Programmieren Architekten?

Eine weitere wichtige Frage ist, ob Architekten selbst programmieren. Traditionelle Architekten tun das nicht. Schließlich arbeiten sie nicht auf der Ebene von Code sondern auf der abstrakteren Ebene der Architektur. Das kann zu dem Elfenbeinturm-Effekt führen, weil Architekten dann das System auf Ebene von Code und damit die Details des Systems nicht sehen. Um dieses Problem zu lösen, ist es aber wie schon erwähnt viel besser, auf die Kommunikation mit dem Team zu setzen. Also ist der Elfenbeinturm-Effekt kein ausreichender Grund, um als Architekt zu coden.

In einem größeren Projekt kann die Architektur-Arbeit so umfassend sein, dass eine Person damit vollständig beschäftigt ist. Da Software-Architekt aber eine Rolle ist, können sich natürlich auch mehrere Personen die Arbeit teilen. Weil Architektur kollaborativ ist, werden sowieso mehrere Personen an der Architektur beteiligt sein. Dennoch kann es sinnvoll sein, die Arbeit auf möglichst wenige Personen zu konzentrieren, um weniger Abstimmung zwischen Architekten zu erreichen. Ein weiteres Problem ist, dass Architekten in erster Linie für die Architektur zuständig sein sollten. Wenn sie dringend Architektur-Arbeit leisten müssen, werden sie das Programmieren vernachlässigen. Das kann sie zu unzuverlässigen Programmierern machen.

Also können Architekten selbst programmieren oder auch nicht. Beides sind Möglichkeiten, wie man die Rolle ausgestalten kann. Den Elfenbeinturm-Effekt kann und muss man bei beiden Ansätzen vermeiden, und zwar durch intensive Kommunikation.

Eine Analogie kann ein Fußball-Trainer sein: Eine solche Person weiß, wie man Fußball spielt, aber tut es nicht mehr selbst aktiv. Insbesondere wird sich der Trainer nicht selbst einwechseln, um das entscheidende Tor zu schießen. Für Software-Architekten gilt ähnliches: Sie sollten wissen, wie man programmiert, aber sie müssen es nicht mehr zwangsläufig selbst tun. Insbesondere komplexe Aufgaben oder Aufgaben, bei denen ein hoher Druck existiert, sollten sie lieber anderen überlassen.

Links & Literatur

  1. https://kylecordes.com/2015/fowler–software–architecture  ↩

  2. https://arc42.de/  ↩

  3. https://de.wikipedia.org/wiki/Pandemie_(Spiel)  ↩

Fazit

Das Ziel einer Software Architektur sollte sein, ein technisches Problem mit Hilfe von Software zu lösen. Meistens wird unter der Architektur die Aufteilung eines Systems in Komponenten verstanden oder die Definition der zu verwendenden Technologien. Das ist aber oft überhaupt nicht geeignet, um die Probleme wirklich zu lösen. Ein wichtiges Hilfsmittel sind der Qualitätsbaum und Qualitätsszenarien, weil so die Anforderungen an die Architektur offensichtlich und sogar verifizierbar werden. Für diese Ziele sollte die Architektur dann Maßnahmen definieren, mit denen diese Ziele auch erreicht werden können. Typischerweise hilft die Strukturierung des Systems bei der Lösung der Probleme nur begrenzt. Dieser lösungsorientierte Teil der Architektur-Arbeit ist sehr wichtig, aber findet in den meisten Projekten überhaupt nicht oder nur eingeschränkt statt. Gerade deswegen ist es so wichtig, diesen Teil der Architektur-Arbeit zu verinnerlichen und umzusetzen.

Die Architektur-Arbeit selbst ist ein kollaborativer Prozess, bei denen das Team gemeinsam Entscheidungen trifft und umsetzt. Der Architekt ist der Moderator dieser Prozesse. Die Entscheidungen werden zwangsläufig auf unvollständigen Informationen basieren. Daher ist es wichtig, Entscheidungen so spät wie möglich zu treffen, weil mit der Zeit mehr und bessere Informationen vorliegen. Statt zu viel Aufwand in die Entscheidungen zu investieren, ist es wichtiger, zu erkennen, wann eine Entscheidung revidiert werden muss und sie dann auch tatsächlich zu revidieren.

Und schließlich muss ein Architekt nicht selbst programmieren, kann das aber durchaus tun. Wenn der Architekt nicht selbst programmiert, kennt er zwar das System nicht auf der Code-Ebene. Einen Elfenbeinturm-Effekt kann er dennoch verhindern, indem er mit den anderen Teammitgliedern kommuniziert, was die Basis der Architektur-Arbeit sein sollte.

TAGS

Comments

Please accept our cookie agreement to see full comments functionality. Read more