Was Softwarearchitektur ist: die Standarddefinitionen und ihre Gemeinsamkeiten

Warum das Wort überhaupt eine Definition braucht

Fragen Sie zehn erfahrene Fachleute, was Softwarearchitektur ist, und Sie hören zehn verschiedene Antworten: das Kästchen-und-Pfeile-Diagramm an der Wand, die Wahl des Cloud-Anbieters, das Datenbankschema, die Aufteilung in Services, die Regeln, welcher Code welchen aufrufen darf, oder einfach „die schwierigen Entscheidungen“. Jede Antwort erfasst etwas Reales, und jede für sich allein lässt etwas aus. Ein Kurs, der Architektur lehren will, muss daher zuerst genau sagen, wovon er spricht.

Das hat praktische Gründe. Wenn ein Team glaubt, Architektur sei „das Diagramm“, hört es auf hinzusehen, sobald das Diagramm gezeichnet ist, obwohl sich das System darunter weiter verändert. Wenn es glaubt, Architektur sei „der Technologie-Stack“, streitet es über Frameworks und übersieht, wie Verantwortlichkeiten aufgeteilt sind und wie Daten fließen. Eine gute Definition sagt Ihnen, worauf Sie achten, was Sie schützen und was Sie mit anderen besprechen sollten.

Die folgenden Definitionen stammen aus einem internationalen Standard, vom Software Engineering Institute (SEI) der Carnegie Mellon University und aus der Praxis. Sie wurden für unterschiedliche Zwecke geschrieben, stimmen aber mehr überein, als sie sich widersprechen, und die Punkte, in denen sie übereinstimmen, bilden den Kern der Disziplin.

Die Standarddefinition: ISO/IEC/IEEE 42010:2022

ISO/IEC/IEEE 42010 ist der internationale Standard für die Beschreibung von Architekturen. Seine aktuelle Ausgabe, veröffentlicht im November 2022, hat die Ausgabe von 2011 ersetzt. Er definiert Architektur, eng umschrieben, als die grundlegenden Konzepte oder Eigenschaften eines Betrachtungsgegenstands in seiner Umgebung, zusammen mit den maßgebenden Prinzipien für dessen Realisierung und Weiterentwicklung und für die zugehörigen Lebenszyklusprozesse.

Drei Merkmale dieser Definition verdienen Aufmerksamkeit. Erstens spricht sie von einem Betrachtungsgegenstand, nicht nur von einem Softwaresystem. Die Ausgabe von 2022 hat den Geltungsbereich bewusst erweitert, sodass dieselben Ideen für Software, Systemverbünde, Produkte, Produktlinien und ganze Unternehmen gelten. Zweitens stellt sie den Gegenstand in seine Umgebung: Eine Architektur lässt sich nicht verstehen ohne die Nutzer, anderen Systeme, Organisation, Gesetze und Budgets um sie herum. Drittens umfasst sie maßgebende Prinzipien dafür, wie der Gegenstand gebaut wird und wie er sich verändert. Architektur ist nicht nur eine Momentaufnahme der Struktur; sie umfasst die Regeln, die die Struktur stimmig halten, während sich das System weiterentwickelt, etwa „jeder Service besitzt seine eigenen Daten“ oder „der Domänencode hängt nie vom Web-Framework ab“.

Der Standard zieht außerdem eine scharfe Linie zwischen einer Architektur und einer Architekturbeschreibung. Die Architektur ist die Menge der grundlegenden Eigenschaften, die das System tatsächlich hat. Die Beschreibung ist ein Arbeitsergebnis (Dokumente, Modelle, Diagramme, Entscheidungsprotokolle), das sie ausdrückt. ISO/IEC/IEEE 42010 ist vor allem ein Standard über Beschreibungen: Er legt fest, was eine gute Beschreibung enthalten sollte, etwa die identifizierten Stakeholder, ihre Anliegen und Sichten, die diese Anliegen behandeln. Er sagt Ihnen nicht, wie Sie eine Architektur entwerfen. Abschnitt 1.5 kommt auf Stakeholder und Anliegen zurück, und Kapitel 4 behandelt Sichten.

Die SEI-Definition: Strukturen, Elemente, Beziehungen und Eigenschaften

Die am häufigsten gelehrte Definition stammt aus Software Architecture in Practice von Len Bass, Paul Clements und Rick Kazman (4. Auflage, Addison-Wesley, 2021), deren Autoren am SEI tätig waren. Sinngemäß in ihren Worten: Die Softwarearchitektur eines Systems ist die Menge der Strukturen, die man braucht, um über das System nachzudenken, und diese Strukturen bestehen aus Software-Elementen, den Beziehungen zwischen ihnen und den Eigenschaften beider.

Jeder Teil dieses Satzes leistet etwas. Strukturen, im Plural: Ein System hat viele Strukturen zugleich (seine Codemodule, seine laufenden Prozesse, seine Verteilung auf Maschinen), und keine einzelne davon ist „die“ Architektur. Die man braucht, um über das System nachzudenken: Ob etwas architekturrelevant ist, zeigt sich daran, ob Sie es brauchen, um wichtige Fragen zu beantworten, etwa „Übersteht das die Spitzenlast?“ oder „Können zwei Teams unabhängig daran arbeiten?“. Elemente sind die Teile: Module, Services, Datenbanken, Queues. Beziehungen sind die Art, wie sie verbunden sind: nutzt, ruft auf, veröffentlicht an, ist deployt auf. Eigenschaften bestimmen, wie sich Elemente und Beziehungen verhalten: Ein Service ist zustandslos, ein Aufruf ist synchron mit einem Timeout von zwei Sekunden, eine Datenbank enthält personenbezogene Daten und muss in der EU bleiben.

Die Formulierung über das Nachdenken erklärt auch, was keine Architektur ist. Der Name einer lokalen Variable, der interne Algorithmus einer Sortierroutine oder das Layout eines Einstellungsbildschirms helfen meist nicht, über das System als Ganzes nachzudenken; sie gehören daher zum Feinentwurf und nicht zur Architektur. Abschnitt 1.2 untersucht, wo diese Grenze verläuft.

Definitionen aus der Praxis: gemeinsames Verständnis, das Wichtige und Entscheidungen

Praktiker haben kürzere Definitionen vorgeschlagen, die Menschen und Entscheidungen statt Strukturen betonen. Martin Fowler hat zwei von Ralph Johnson bekannt gemacht (einem der vier Autoren des Buchs Design Patterns von 1994). Die erste lautet, Architektur sei das gemeinsame Verständnis, das die erfahrenen Entwickler davon haben, wie das System entworfen ist. Die zweite, aus derselben Diskussion, ist bewusst offen gehalten: Bei Architektur geht es um das Wichtige. Was immer das ist. Johnson schlug außerdem vor, Architektur sei die Menge der Entscheidungen, die man gern früh in einem Projekt richtig treffen würde, nicht weil man sie früh eher richtig trifft, sondern weil ein Fehler bei ihnen so teuer ist.

Grady Booch, einer der Schöpfer der UML, fasste es ökonomisch: Architektur besteht aus den bedeutsamen Designentscheidungen, die ein System prägen, wobei Bedeutsamkeit an den Änderungskosten gemessen wird. Das macht aus einer abstrakten Idee einen brauchbaren Test. Die Farbe eines Buttons zu wählen, lässt sich billig rückgängig machen. Die Wahl zwischen einer relationalen Datenbank und einem Dokumentenspeicher oder zwischen einer deploybaren Einheit und vierzig ist teuer rückgängig zu machen, sobald Daten, Code und Teams darum herum gewachsen sind. Booch stellte auch fest, dass jede Architektur Design ist, aber nicht jedes Design Architektur.

Diese Definitionen ergänzen etwas, das die strukturellen offenlassen. Architektur lebt zum Teil in den Köpfen der Menschen; ein System, dessen erfahrene Fachleute ein klares gemeinsames Bild davon haben, wie es funktioniert, hat eine stimmigere Architektur als eines, bei dem jeder ein anderes Bild im Kopf hat, selbst wenn keines von beiden ein Diagramm besitzt. Und Architektur wird durch Entscheidungen geprägt, von denen viele eine Abwägung erfordern: Wer sich für eine Option entscheidet, verzichtet auf die Vorteile einer anderen. Abschnitt 1.6 behandelt Entscheidungen und Abwägungen im Detail.

Was die Definitionen gemeinsam haben

Nebeneinander gelesen, laufen die Definitionen auf sieben Ideen zusammen, die gemeinsam eine Arbeitsdefinition für den restlichen Kurs bilden.

Drei Arten von Strukturen

Die Arbeit des SEI zur Dokumentation, veröffentlicht als Documenting Software Architectures: Views and Beyond (Clements und Kollegen, 2. Auflage, 2010), teilt Strukturen in drei Arten ein, und Software Architecture in Practice verwendet dieselbe Einteilung. Wer die drei Arten kennt, ist vor dem häufigsten Fehler in Architekturdiskussionen geschützt: über eine Art von Struktur zu sprechen, während das Gegenüber an eine andere denkt.

Modulstrukturen zeigen, wie der Code in Implementierungseinheiten aufgeteilt ist, etwa Pakete, Bibliotheken und Namensräume, und wie diese Module voneinander abhängen. Sie existieren zur Entwicklungszeit. Sie beantworten Fragen wie: Welches Team kann was ändern, ohne anderen etwas kaputtzumachen, und welcher Code lässt sich wiederverwenden?

Komponenten-und-Konnektoren-Strukturen zeigen, was existiert, wenn das System läuft: Prozesse, Services, Clients, Datenbanken und die Konnektoren dazwischen, etwa HTTP-Aufrufe, Message Queues und Event-Streams. Sie beantworten Laufzeitfragen: Wie schnell ist eine Anfrage, was passiert, wenn ein Teil ausfällt, wo liegen die Daten?

Zuordnungsstrukturen bilden Software auf Dinge außerhalb der Software ab: auf Hardware und Cloud-Infrastruktur (Deployment), auf Teams (Arbeitszuteilung) und auf Dateien und Repositorys (Implementierung). Sie beantworten Fragen zu Kosten, Betrieb und Organisation: Wo läuft es, wer baut es, wer wird nachts geweckt, wenn es ausfällt?

Ein Element kann in allen dreien vorkommen. Eine Checkout-Funktion ist in der Modulstruktur ein Paket, in der Komponenten-und-Konnektoren-Struktur ein laufender Service und in den Zuordnungsstrukturen eine Menge von Containern in einer Cloud-Region, die dem Checkout-Team gehören. Die Abbildung zwischen den Strukturen ist nicht immer eins zu eins: Ein einzelnes Modul kann als mehrere Services deployt werden, oder mehrere Module laufen in einem Prozess. Genau in dieser Lücke verbergen sich viele Überraschungen.

Jedes System hat eine Architektur

Weil Architektur aus Strukturen und den Eigenschaften besteht, die sie tatsächlich haben, hat jedes Softwaresystem eine Architektur, ob sie jemand absichtlich entworfen hat oder nicht und ob sie aufgeschrieben ist oder nicht. Ein Tabellenkalkulationsmakro, das zu einem geschäftskritischen Werkzeug gewachsen ist, hat eine Architektur. Ebenso die Codebasis eines Start-ups, die drei Leute in Eile geschrieben haben. Die Frage ist nie, ob ein System eine Architektur hat, sondern ob diese Architektur ihren Zweck erfüllt, von den Menschen verstanden wird, die daran arbeiten, und bewusst gestaltet ist.

Daraus ergibt sich eine nützliche Unterscheidung. Die beabsichtigte (oder präskriptive) Architektur ist das, was das Team für die richtige Struktur hält oder beschlossen hat: das Diagramm im Wiki, die vereinbarten Regeln. Die tatsächliche (oder deskriptive) Architektur ist das, was Code und Infrastruktur wirklich tun. Beide driften mit der Zeit auseinander, wenn niemand sie in Einklang hält, und diese Lücke ist eine der Hauptquellen technischer Schulden, die in Abschnitt 1.7 behandelt werden. Eine undokumentierte Architektur fehlt nicht; sie ist nur schwerer zu sehen, zu durchdenken und sicher zu ändern.

Wie Fachleute die Definitionen nutzen

In der Praxis sagen erfahrene Architekten selten eine Definition auf, aber sie nutzen jede als Linse. Die ISO-Sicht erinnert sie daran, nach außen auf die Umgebung zu schauen und das, was das System ist, von dem zu trennen, was die Dokumente sagen. Die SEI-Sicht gibt ihnen ein Vokabular aus Strukturen, Elementen, Beziehungen und Eigenschaften für die Analyse und einen Test („Brauchen wir das, um über das System nachzudenken?“). Johnsons Sicht erinnert sie daran, dass ein gemeinsames mentales Modell im Team selbst ein Wert ist, der gepflegt werden muss. Boochs Sicht sagt ihnen, wofür sie ihre begrenzte Zeit einsetzen sollten: für die Entscheidungen, die teuer rückgängig zu machen wären.

Daraus folgt eine praktische Faustregel. Wenn Sie unsicher sind, ob etwas architekturrelevant ist, stellen Sie drei Fragen. Wäre es später teuer oder riskant, es zu ändern? Betrifft es mehrere Teile des Systems oder mehrere Teams? Entscheidet es darüber, ob das System ein wichtiges Qualitätsziel erreicht, etwa Geschwindigkeit, Verfügbarkeit oder Sicherheit? Lautet die Antwort auf eine dieser Fragen Ja, behandeln Sie es als Architektur: Entscheiden Sie es bewusst, halten Sie die Gründe fest und sorgen Sie dafür, dass die Betroffenen es verstehen.