Softwarearchitektur: Worauf es ankommt von Eberhard Wolff

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

Eberhard Wolff

Eberhard Wolff ist Fellow bei INNOQ und arbeitet seit mehr als fünfzehn Jahren als Architekt und Berater. Er ist Autor zahlreicher Artikel und Bücher und trägt als Sprecher auf internationalen Konferenzen vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Continuous Delivery, DevOps und Microservices.

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

Ein Gedankenexperiment zeigt, inwieweit diese Definition ausreichend ist: Eine Software geht nicht in Produktion – ein Sicherheitsproblem und ein Problem mit der Compliance wurden entdeckt. 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 Softwarearchitektur etwas anderes umfassen als nur die Struktur des Systems, denn offensichtlich können auch andere Faktoren zu einem Architekturfehlschlag führen.

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

Eine andere Möglichkeit, Softwarearchitektur zu definieren, ist relativ simpel: Softwarearchitektur bedeutet, dass man eine technische Softwarelösung für das jeweilige Problem entwirft. Diese Definition ist nicht sonderlich spezifisch. Sie passt zu allen Arten von technischen Ingenieursdisziplinen. Aber sie 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 Architekturdokumentationen zwar fast immer eine Darstellung der grobgranularen Struktur des Systems, aber fast nie Informationen darüber, 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, die weithin genutzt werden. Es gibt auch Werkzeuge, um das Problem besser verstehen und darstellen zu können. Die sind aber bei weitem nicht so bekannt. ISO 25010 definiert dafür den Qualitätsbaum. Auch Standards für die Architekturdokumentation wie arc42 [2] beinhalten solche Aspekte. Abbildung 1 zeigt einen Ausschnitt aus dem Qualitätsbaum, in dem verschiedene Qualitätsmerkmale wie Sicherheit oder Zuverlässigkeit aufgelistet sind.

Für jedes Qualitätsmerkmal gibt es eine Liste von Teilmerkmalen, die es einfacher machen, ein Qualitätsmerkmal wirklich vollständig zu betrachten. Bei Zuverlässigkeit geht die Diskussion oft schnell in die Richtung Verfügbarkeit. Ein Blick in den Qualitätsbaum zeigt weitere Teilmerkmale wie Fehlertoleranz, was 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 ist in der Abbildung nur ein beispielhaftes Teilmerkmal aufgelistet: die Nachweisbarkeit. Es kann sein, dass Benutzerinteraktionen 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

Aber der Qualitätsbaum reicht nicht aus: Die Einhaltung der Qualitätsmerkmale können nur schlecht verifiziert werden. Doch auch dafür gibt es ein geeignetes Softwarearchitekturwerkzeug: Das Qualitätsszenario (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. Diese Metrik sorgt dafür, dass das Qualitätsszenario konkret und leicht zu verifizieren ist. Es gibt verschiedene Arten von Szenarien, die im Folgenden dargestellt werden.

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 Benutzertests einplanen. Solche Maßnahmen gehören nicht zur klassischen Architekturarbeit, 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, 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 Speichersystem oder ein Backup ausreichen. Ein Cluster wäre als Lösung zwar auch 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 Architekturbeschreibungen. So kann aber nicht garantiert werden, dass die entwickelten Systeme die Probleme überhaupt lösen.

Eine „gute“ Architektur wird oft mit hoher Codequalität, einer sauberen Struktur oder guter Skalierbarkeit gleichgesetzt. Aber keine dieser Eigenschaften hätte auch nur ansatzweise dabei geholfen, eines 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 des Projekts entwickeln will, ist die traditionelle Architekturarbeit 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 Softwarearchitekten. Obwohl dieser Aspekt so ein Schattendasein führt, ist er dennoch sehr wichtig. Traditionell ist „Softwarearchitekt“ ein Titel und oft auch eine Stufe auf der Karriereleiter. Die moderne Interpretation des Softwarearchitekten ist anders: Es ist die Person, die Architektur macht. Und es ist eine Rolle: Zu unterschiedlichen Zeiten können unterschiedliche Personen die Rolle Softwarearchitekt innehaben. Diese Personen können den entsprechenden Titel haben oder auch nicht. Wenn man die erwähnten Qualitätsszenarien betrachtet, deren Erfüllung zur Architektur gehört, können klassische Architekten nur wenige dieser Qualitätsszenarien erfüllen.

Oft wird an traditionelle Softwarearchitekten die Anforderung gestellt, die technologieerfahrensten Personen im Team zu sein. Schließlich treffen Architekten Entscheidungen, die weitreichende Konsequenzen haben. Zweifellos müssen sie daher die besten Qualifikationen 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 Softwarearchitekten 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 er lernen könnte.

Die moderne Interpretation der Rolle Softwarearchitekt 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 Teammitglieder 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: Softwareentwicklung 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 Softwarearchitekt das System nicht vollständig und in allen Details verstehen. Auch er muss für das Verständnis des Systems auf die Expertise des Teams zurückzugreifen. Jeder Mitarbeiter im Team kennt einen bestimmten Teil oder 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 Projekte agil nach Scrum entwickelt. Scrum kennt die Rolle des Product Owners. 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 Teammitglied sein. Dann kann der Architekt aber die Architektur nicht durchsetzen. Schließlich ist das Team selbstorganisiert, 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 er es dürfte, bleibt die Frage offen, wie er zum Durchsetzen der Architektur konkret vorgehen sollte. Da er nicht wissen kann, was im Projekt alles vorgeht, ist es schwierig, die Architektur durchzusetzen. Es kann passieren, dass das Team die Architektur gar nicht umsetzt, der Architekt das aber nicht merkt, weil er eben nicht das gesamte System verstehen kann.

Der Elfenbeinturmeffekt

So kommt es leicht zum Elfenbeinturmeffekt: Der Architekt versteht die Herausforderungen des Systems nicht, weil er das System nicht vollständig verstehen kann und mit den anderen Teammitgliedern nicht ausreichend kommuniziert. Auf Basis dieser falschen Informationen trifft er Architekturentscheidungen, 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 Auswirkungen auf das Projekt.

Eine moderne Interpretation der Rolle „Systemarchitekt“ 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. Dieses Vorgehen vermeidet den Elfenbeinturmeffekt.

Die Rolle „Softwarearchitekt“ 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.

Softwarearchitektur: ein kollaboratives Spiel

Softwarearchitektur erinnert damit an kollaborative Spiele wie Pandemie [3]. Im Gegensatz zu anderen Spielen gewinnen oder verlieren bei einem kollaborativen Spiel alle gemeinsam. Das ist bei einem Softwareprojekt nicht anders: Wenn das Projekt nicht erfolgreich ist, verlieren dabei alle. Bei Pandemie geht es darum, den Ausbruch einer Pandemie zu vermeiden. Die Figuren 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 besondere Vorteile zu erreichen. So kann der Logistiker den Arzt dahin schicken, wo gerade besonders viele Infizierte sind. Die besten Synergien herauszufinden und ein gemeinsames Handeln zu planen und umzusetzen, das ist 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 anderes am Zug ist. Spezielle Fähigkeiten und spezielles Wissen zeichnen auch die Teammitglieder in einem Softwareprojekt aus. Und auch in einem Softwareprojekt ist Kommunikation der Schlüssel, um das Projekt erfolgreich umzusetzen.

Entscheidungen

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

Also muss man sich daran gewöhnen, ständig auf Basis von zu wenigen Informationen zu entscheiden – das setzt Mut voraus. Es gibt aber 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 (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 Start-up entwirft ein IT-System, das natürlich Rechnungen erstellen können soll, denn sonst gibt es keinen Umsatz. Offensichtlich ist das Erstellen der Rechnungen ein wichtiges Feature und man muss eine Architektur dafür definieren. Wer schon mal selbstständig war, kennt das manuelle Schreiben von Rechnungen, man kann also durchaus auch Rechnungen ohne Automatisierung erstellen. Nun hat dieses IT-System ein Abomodell, nach dem am Monatsende abgerechnet wird. Wenn die ersten Kunden da sind, hat man also noch einen Monat Zeit, das automatische Erstellen der Rechnungen zu implementieren und kann die Arbeit an diesem Teil der Architektur erstmal zurückstellen. Wenn man tatsächlich mit der Architektur daran 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 mit Sicherheit auch 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 revidieren müssen wird. Wenn man nicht auf neue Informationen reagiert, wird die Architektur darunter leiden. Die Erklärung für die meisten Architekturprobleme ist nicht, dass sich die Architekten nicht genug angestrengt haben, sondern dass es neue Erkenntnisse gab, die nicht in die Architektur eingeflossen sind, weil die Architektur nicht revidiert wurde.

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 zum Elfenbeinturmeffekt führen, weil Architekten dann das System auf der Codeebene nicht sehen. Um dieses Problem zu lösen, ist es aber viel besser, auf die Kommunikation mit dem Team zu setzen. Also ist der Elfenbeinturmeffekt kein ausreichender Ansporn, um als Architekt zu coden.

In einem größeren Projekt kann die Architekturarbeit so umfassend sein, dass eine Person vollständig damit beschäftigt ist. Da der Softwarearchitekt aber eine Rolle ist, können sich natürlich auch mehrere Personen die Arbeit teilen, und da Architektur kollaborativ ist, werden sowieso mehrere Personen an der Architektur beteiligt sein. Dennoch kann es sinnvoll sein, die Arbeit auf wenige Personen zu konzentrieren, um weniger Abstimmungsbedarf zwischen Architekten zu erreichen. Ein weiterer Punkt ist, dass Architekten in erster Linie für die Architektur zuständig sind. Wenn sie also dringende Architekturarbeit leisten müssen, werden sie das Programmieren vernachlässigen. Das kann sie zu unzuverlässigen Programmierern machen. Schlussendlich können Architekten selbst programmieren oder auch nicht. Beides sind Möglichkeiten, die Rolle auszugestalten. Den Elfenbeinturmeffekt kann und muss man bei beiden Ansätzen vermeiden.

Eine Analogie kann ein Fußballtrainer sein: Der weiß, wie man Fußball spielt, aber tut es nicht mehr selbst. Insbesondere wird sich der Trainer nicht selbst einwechseln, um das entscheidende Tor zu schießen. Für Softwarearchitekten 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.

Fazit

Das Ziel einer Softwarearchitektur sollte sein, ein technisches Problem mit Hilfe von Software zu lösen. Meistens wird unter der Architektur die Aufteilung eines Systems in Komponenten oder die Definition der zu verwendenden Technologien verstanden. Das hilft aber meist nicht, um die eigentlichen Probleme zu lösen. Wichtige 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. Dieser Teil der Architekturarbeit 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 Architekturarbeit zu verinnerlichen und umzusetzen.

Die Architekturarbeit selbst ist ein kollaborativer Prozess, bei dem 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. Wichtiger als viel Aufwand in die Entscheidungen zu investieren, ist es, zu erkennen, wann eine Entscheidung revidiert werden muss und das dann auch tatsächlich zu tun.

Und schließlich muss ein Architekt nicht selbst programmieren, kann das aber durchaus tun. Wenn der Architekt nicht selbst programmiert, kennt er das System zwar nicht auf der Codeebene, kann einen Elfenbeinturmeffekt aber dennoch verhindern, indem er mit den anderen Teammitgliedern kommuniziert, was die Basis der Architekturarbeit sein sollte.