Was Softwarearchitektur ist

Willkommen zu Kapitel 1: Was Softwarearchitektur ist. Kapitel null hat Ihnen die Bausteine gegeben. Dieses Kapitel tritt einen Schritt zurück und fragt, was es heißt, diese Bausteine bewusst anzuordnen, wer das tut und warum sich der Aufwand lohnt. Es gibt Ihnen das Vokabular für den restlichen Kurs und eine Denkweise für jedes System, von einer kleinen Buchungs-App bis zu einer nationalen Zahlungsplattform.

Jedes Softwaresystem hat eine Architektur, ob sie jemand entworfen hat oder nicht. Sie ist die Menge der grundlegenden Strukturen, aus denen das System besteht, und der bedeutsamen Entscheidungen, die sie hervorgebracht haben. Diese Strukturen entscheiden weit mehr, als den meisten bewusst ist: wie schnell und zuverlässig das System ist, was sein Betrieb kostet und wie viele Teams gleichzeitig daran arbeiten können. Vor allem entscheiden sie, wie teuer es sein wird, das System im nächsten Jahr zu ändern. Features sind das, was ein System tut. Die Architektur entscheidet weitgehend, wie gut es das tut und was es kostet, etwas anderes zu tun.

Dieses Kapitel richtet sich an Entwickler, die in Architekturverantwortung hineinwachsen. Es ist auch für alle, die mit Architekten zusammenarbeiten und verstehen wollen, was sie tun und warum. Es baut auf den Bausteinen aus Kapitel null auf: Komponenten, Datenspeicher, Netzwerke und APIs. Wenn Sie damit vertraut sind, sind Sie bereit. Und es führt zu Kapitel 2, das die Ziele einer Architektur als Qualitätsmerkmale präzise und messbar macht.

Das Kapitel hat acht Abschnitte. Abschnitt eins Punkt eins vergleicht die maßgeblichen Definitionen, vom internationalen Standard und vom Software Engineering Institute, kurz SEI, bis zu Praktikern, die gemeinsames Verständnis und schwer änderbare Entscheidungen betonen. Abschnitt eins Punkt zwei geht die häufigste Verwechslung an: wo Architektur endet und Design beginnt. Die Antwort: Es gibt keine Mauer, nur ein Kontinuum, geordnet nach Bedeutsamkeit. Abschnitt eins Punkt drei begründet, warum Architektur wichtig ist, anhand von drei echten Fällen: dem Handelsverlust von Knight Capital im Jahr zweitausendzwölf, dem holprigen Start von HealthCare Punkt gov im Jahr zweitausenddreizehn und einer Umstellung bei Amazon Prime Video im Jahr zweitausenddreiundzwanzig.

Dieses Diagramm aus Abschnitt eins Punkt eins zeigt am Beispiel eines Essenslieferdienstes, was die Definitionen gemeinsam haben. Die gestrichelte Linie ist die Systemgrenze. Die Kästen darin sind Elemente: eine mobile App, ein Bestellservice, eine Bestelldatenbank, ein Kurierservice und ein Zahlungsmodul. Die Pfeile sind Beziehungen. Die App ruft den Bestellservice über HTTPS auf. Der Bestellservice fragt die Datenbank mit SQL ab und sendet ein Ereignis an den Kurierservice. Kleine Beschriftungen halten Eigenschaften fest. Der Bestellservice zum Beispiel ist zustandslos und läuft in drei Kopien. Außerhalb der Grenze liegt die Umgebung: Kunden, Kuriere und Restaurants sowie der Kartenzahlungsanbieter. Und die Umgebung umfasst mehr als andere Systeme. Dazu gehören auch Recht, Budget, die Organisation und ihre Teams sowie die Cloud-Plattform. Ohne sie lässt sich eine Architektur nicht verstehen.

Abschnitt eins Punkt vier wendet sich den Menschen zu: was Architekten tatsächlich tun, welche Arten es gibt, warum Architektur eine Rolle ist, bevor sie eine Berufsbezeichnung ist, und die lange Debatte, ob Architekten noch Code schreiben sollten. Abschnitt eins Punkt fünf weitet den Blick auf die Stakeholder, also alle, die ein Interesse am System haben, von Nutzern und Entwicklern bis zu Aufsichtsbehörden. Er zeigt, wie widersprüchliche Anliegen explizit gemacht werden, statt von dem entschieden zu werden, der am lautesten ruft. Abschnitt eins Punkt sechs widmet sich Entscheidungen und Abwägungen: was eine gute Entscheidung enthält, welche Entscheidungen leicht umkehrbar sind und welche nicht, und der Idee, zum Last Responsible Moment zu entscheiden.

In den letzten beiden Abschnitten geht es um Zeit. Abschnitt eins Punkt sieben erklärt technische Schulden so, wie Ward Cunningham sie ursprünglich gemeint hat, wie sie sich von bloßer Unordnung unterscheiden und wie Architekturen erodieren und von ihrer beabsichtigten Form abdriften. Abschnitt eins Punkt acht verortet Architektur im Lebenszyklus zwischen Big Design Up Front und rein emergentem Design und zeigt einen praktischen Mittelweg: gerade genug Architektur, zum richtigen Zeitpunkt, laufend überprüft.

Dieses Diagramm aus Abschnitt eins Punkt zwei zeigt, wie man Architektur von Design unterscheidet. Entscheidungen weiter links sind architekturrelevanter, weiter rechts eher eine Frage von Design und Code. Der erste Test sind die Kosten, eine Entscheidung rückgängig zu machen: Monate Arbeit für viele Teams am einen Ende, Minuten für eine Person am anderen. Der zweite ist die Reichweite: das ganze System oder die ganze Organisation oder nur eine Funktion oder Klasse. Der dritte ist die Wirkung auf zentrale Qualitätsmerkmale. Die Punkte setzen eine echte Entscheidung, die Wahl des Nachrichtenformats, auf jede Linie, und auf allen drei neigt sie zum architektonischen Ende.

Wenn Sie sich aus diesem Kapitel nur eines merken, dann dies. Architektur ist die Menge der Entscheidungen, bei denen ein Fehler teuer wird. Die Aufgabe des Architekten ist, diese Entscheidungen zu erkennen, sie bewusst mit den richtigen Leuten zu treffen, die Gründe festzuhalten und sie im Blick zu behalten, während möglichst viele andere Entscheidungen billig änderbar bleiben. Der restliche Kurs wendet diesen Gedanken an.

Sie können die Abschnitte der Reihe nach lesen, was sich empfiehlt, wenn die Ideen neu sind, oder gezielt die auswählen, die Sie brauchen. Das ganze Kapitel dauert etwa zweieinhalb Stunden Lesezeit. Jeder Abschnitt endet mit einigen Fragen zur Selbstkontrolle. Versuchen Sie, sie im Kopf zu beantworten, bevor Sie nachsehen, damit Sie merken, was hängen geblieben ist. Wenn Sie so weit sind, gibt es einen freiwilligen Kapiteltest mit zwanzig Multiple-Choice-Fragen und zwei schriftlichen Antworten. Planen Sie etwa fünfundvierzig Minuten ein. Die Bestehensgrenze liegt bei achtzig Prozent, wie bei jedem Kapiteltest im Kurs.

Das ist die Übersicht über Kapitel 1. Beginnen Sie mit Abschnitt eins Punkt eins, wo wir die Standarddefinitionen der Softwarearchitektur vergleichen und herausarbeiten, was sie gemeinsam haben. Bis gleich.