Architektur, Design und Code: Bedeutsamkeit, Reichweite und Ebenen

Ein Kontinuum, keine Mauer

Wenn Architektur die Menge der bedeutsamen Entscheidungen und Strukturen ist (Abschnitt 1.1), dann ist Design alles Übrige: die vielen kleineren Entscheidungen darüber, wie jeder Teil im Inneren funktioniert. Die Schwierigkeit ist, dass es keine saubere Grenze zwischen beidem gibt. Eine Essenslieferplattform in ein Bestellsystem und ein Kuriersystem aufzuteilen, ist eindeutig eine Architekturentscheidung. Eine Variable zu benennen, ist es eindeutig nicht. Zwischen diesen Extremen liegt ein breites Mittelfeld von Entscheidungen (das Fehlerformat einer API, eine Caching-Regel, die Aufteilung eines Moduls in Pakete), deren Status vom Kontext abhängt.

Grady Booch hat es treffend formuliert: Jede Architektur ist Design, aber nicht jedes Design ist Architektur. Architektur und Feinentwurf sind Punkte auf einem Kontinuum von Designentscheidungen, geordnet danach, wie bedeutsam sie sind. Deshalb lautet die nützlichste Frage nicht abstrakt „Ist das Architektur oder Design?“, sondern „Wie bedeutsam ist diese Entscheidung hier, und wie viel Sorgfalt verdient sie?“.

Eine zweite, beliebte Art, die Grenze zu ziehen, ist die Abstraktionsebene: Architektur ist die Sicht von oben („Kästchen und Pfeile“), Design die Sicht im Detail („Klassen und Methoden“). Das ist eine vernünftige erste Näherung, scheitert aber in beide Richtungen. Ein Detail auf niedriger Ebene kann architekturrelevant sein: Das Format einer Kennung, die zwanzig Services gemeinsam nutzen, oder die Wahl einer Zeitzonenkonvention für gespeicherte Datumsangaben kann Monate kosten, wenn man es ändern will. Und ein Kasten auf hoher Ebene kann belanglos sein: Ob ein internes Admin-Tool ein eigener Service ist, spielt womöglich gar keine Rolle.

Was eine Entscheidung architekturrelevant macht

Eine Entscheidung ist architekturrelevant, wenn sie eines oder mehrere der folgenden Merkmale aufweist. Das sind keine formalen Regeln aus einem einzelnen Standard; sie fassen zusammen, was das SEI, Martin Fowler, Mark Richards und Neal Ford und andere mit unterschiedlichen Worten sagen.

Mark Richards und Neal Ford beschreiben in Fundamentals of Software Architecture das Spektrum zwischen Architektur und Design ähnlich: Eine Entscheidung liegt umso näher an der Architektur, je strategischer sie ist (langfristig, viele Beteiligte), je mehr Aufwand eine Änderung erfordern würde und je bedeutsamer ihre Abwägungen sind. Martin Fowler bietet eine kompakte Fassung: Architektur ist das, was schwer zu ändern ist, und daraus folgt auch, dass es eines der Ziele eines Architekten ist, mehr Dinge leicht änderbar zu machen. Eine Entscheidung billig umkehrbar zu machen, etwa indem man sie hinter eine Schnittstelle legt, verschiebt sie faktisch von der Architektur hin zum Design. Diese Idee, die Umkehrbarkeit, wird in Abschnitt 1.6 weiter vertieft.

Strategische und taktische Entscheidungen

Eine verwandte Unterscheidung ist die zwischen strategischen und taktischen Entscheidungen. Strategische Entscheidungen geben für lange Zeit und für viele Menschen die Richtung vor: einen Cloud-Anbieter einführen, zwischen einem Monolithen und verteilten Services wählen, festlegen, dass Kundendaten in einem einzigen System geführt werden. Sie brauchen meist den Input mehrerer Stakeholder, und es lohnt sich, sie mit ihren Gründen aufzuschreiben. Taktische Entscheidungen lösen ein unmittelbares Problem in einem abgegrenzten Bereich: welche Bibliothek ein Service zum Parsen von Datumsangaben nutzt, wie eine bestimmte Datenbankabfrage aufgebaut ist, wie die Endpoints einer internen API heißen.

Strategisch heißt nicht langsam. Viele strategische Entscheidungen können und sollten schnell getroffen werden, sobald die Optionen klar sind, und manche sind umkehrbar, wenn sie gut strukturiert sind. Taktisch heißt nicht unwichtig: Eine schlechte taktische Entscheidung, die an fünfzig Stellen wiederholt wird (etwa wenn jeder Service seine eigene Wiederholungslogik ohne Back-off schreibt), kann sich zu einem Architekturproblem summieren. Architekten achten auf taktische Entscheidungen, die durch Wiederholung gerade strategisch werden, und machen daraus ein gemeinsames Prinzip oder eine Plattformfähigkeit.

Ebenen der Architektur

Das Wort Architektur wird außerdem auf mehreren Ebenen der Reichweite verwendet, und Berufsbezeichnungen folgen diesen Ebenen. Wer sie verwechselt, erzeugt viele Missverständnisse: Ein Unternehmensarchitekt und ein Softwarearchitekt können beide „der Architekt“ sein, und doch überschneidet sich ihre Arbeit kaum.

Unternehmensarchitektur betrachtet eine ganze Organisation: ihre Geschäftsfähigkeiten (was sie können muss, etwa „Schadensfälle prüfen“ oder „Kunden aufnehmen“), die Informationen, die sie hält, ihr Anwendungsportfolio und ihre Technologieplattformen und wie sich all das ändern sollte, um die Strategie zu unterstützen. Typische Ergebnisse sind Capability Maps, Roadmaps zum Zielzustand, Technologiestandards und Entscheidungen darüber, welche Systeme abgelöst werden. Das hier am weitesten verbreitete Framework ist TOGAF, herausgegeben von The Open Group, dessen aktuelle Version der TOGAF Standard, 10th Edition (2022) ist. Es bietet eine Methode (die Architecture Development Method) und einen Fundus an Inhalten für die Planung und Steuerung von Veränderungen im Unternehmen. Organisationen nutzen es in unterschiedlichem Maß; viele übernehmen Teile davon, manche finden es schwergewichtig, und dieser Kurs beschreibt es nur, damit Sie es wiedererkennen.

Lösungsarchitektur befasst sich mit einem Geschäftsproblem oder Programm, das typischerweise mehrere Anwendungen, Teams und Anbieter umfasst: etwa ein Krankenhaus, das eine Online-Terminbuchung einführt, die ein neues Web-Frontend, das bestehende Patientenverwaltungssystem, einen SMS-Anbieter und den Identitätsdienst verbinden muss. Der Lösungsarchitekt sorgt dafür, dass die Teile zusammenpassen, oft unter kaufmännischen und vertraglichen Randbedingungen.

Software- oder Anwendungsarchitektur, das Hauptthema dieses Kurses, betrifft die Strukturen und Qualitäten eines Systems: seine Zerlegung, seine Interaktionen zur Laufzeit, sein Deployment, seine Daten und seine Weiterentwicklung.

Drei Fachgebiete ziehen sich durch alle diese Ebenen. Datenarchitektur umfasst, wie Daten modelliert, verantwortet, gespeichert, bewegt, gesteuert und für Analysen genutzt werden (Kapitel 7). Sicherheitsarchitektur umfasst Identität, Zugriff, Datenschutz, Bedrohungsmodelle und die Platzierung von Sicherheitskontrollen (Kapitel 8). Infrastrukturarchitektur (heute oft Cloud- oder Plattformarchitektur) umfasst Rechenleistung, Netzwerke, Speicher, Umgebungen und Deployment-Plattformen (Kapitel 10).

Wer welche Entscheidungen trifft

In einer gesunden Organisation werden Entscheidungen auf der niedrigsten Ebene getroffen, die genug Kontext hat und für die Folgen verantwortlich ist. Architektur ist nicht das alleinige Eigentum von Leuten mit „Architekt“ im Titel. Eine vernünftige Standardaufteilung sieht so aus, auch wenn jede Organisation sie anpasst.

Zwei Warnsignale zeigen, dass die Aufteilung falsch ist. Wenn Architekten interne Klassenstrukturen festlegen, werden sie zum Engpass, und das Team hört auf mitzudenken. Wenn Teams unabhängig voneinander Entscheidungen mit systemweiter Wirkung treffen (etwa jedes seinen eigenen Message Broker wählt), zahlt die Organisation später für die Uneinheitlichkeit. Wie man festhält, welche Entscheidungen eine breitere Abstimmung brauchen, und wie man das Festhalten leicht macht, wird unter Entscheidungen und Abwägungen und ausführlich in Kapitel 4 bei den Architecture Decision Records behandelt.

Wie Fachleute die Unterscheidung anwenden

Erfahrene Teams machen aus dem Kontinuum eine schlanke Routine. Sie vereinbaren eine kurze Liste der Arten von Entscheidungen, die ein schriftliches Protokoll und eine breitere Abstimmung brauchen, zum Beispiel alles, was eine öffentliche API ändert, einen neuen Datenspeicher oder eine neue Technologie einführt, Teamgrenzen überschreitet oder ein festgelegtes Qualitätsziel berührt. Alles andere entscheiden die Menschen, die die Arbeit machen, über das normale Code-Review. Sie überarbeiten die Liste, wenn etwas durchrutscht oder wenn sich Reviews nach Bürokratie anfühlen.

Sie suchen auch aktiv nach Wegen, die Menge der Architekturentscheidungen zu verkleinern, denn jede Entscheidung, die billig umkehrbar wird, ist eine weniger, die beim ersten Mal richtig sein muss. Einen Anbieter hinter einer Schnittstelle zu verbergen, eine Datenbank zur Privatsache eines Service zu machen, Feature-Flags für riskantes Verhalten zu nutzen und in kleinen Schritten zu deployen, verschiebt Entscheidungen vom architektonischen Ende des Kontinuums zum Design-Ende.