Architekturentscheidungen und Abwägungen: Umkehrbarkeit und Zeitpunkt

Alles ist eine Abwägung

Jede bedeutsame Architekturentscheidung gewinnt etwas, indem sie etwas anderes aufgibt. Wer ein System in unabhängig deploybare Services aufteilt, gewinnt Autonomie der Teams und unabhängige Skalierung und bezahlt mit Netzwerklatenz, betrieblicher Komplexität und schwierigerer Datenkonsistenz. Caching gewinnt Geschwindigkeit und bezahlt mit veralteten Daten und Invalidierungslogik. Eine verwaltete Cloud-Datenbank befreit von Patches und Backups und kostet dafür Geld und Abhängigkeit von einem Anbieter. Mark Richards und Neal Ford stellen dies an den Anfang von Fundamentals of Software Architecture (2020; zweite Auflage 2025), als ihr erstes Gesetz: Alles in der Softwarearchitektur ist eine Abwägung. Als Folgerung leiten sie ab: Wenn Sie glauben, etwas gefunden zu haben, das keine Abwägung ist, haben Sie die Abwägung wahrscheinlich nur noch nicht erkannt.

Ihr zweites Gesetz lautet, dass das Warum wichtiger ist als das Wie. Jeder kann sich ein laufendes System ansehen und erkennen, wie es gebaut ist: drei Services, ein Message Broker, eine Dokumentendatenbank. Was sich aus dem Code nicht rekonstruieren lässt, ist das Warum: welche Alternativen erwogen wurden, welche Anliegen sich durchsetzten, welche Risiken in Kauf genommen wurden. Ohne das Warum bewahren spätere Entwickler entweder Entscheidungen, die keinen Sinn mehr ergeben, oder sie machen Entscheidungen rückgängig, deren Gründe weiterhin gelten. Die zweite Auflage fügt ein drittes Gesetz hinzu: Die meisten Architekturentscheidungen sind nicht binär, sondern liegen auf einem Spektrum zwischen Extremen. Selten wählen Sie zwischen „Monolith“ und „Microservices“; Sie wählen, wie viele deploybare Einheiten es gibt, entlang welcher Linien geschnitten wird und was geteilt wird.

In Abwägungen zu denken ist die Gewohnheit, die architektonisches Denken am deutlichsten von Begeisterung unterscheidet. Wenn jemand eine Technologie vorschlägt, lauten die nützlichen Fragen nicht „Ist sie gut?“, sondern „Was kostet sie, was erschwert sie, und sind diese Kosten angesichts unserer Anliegen akzeptabel?“ Der vorige Abschnitt hat gezeigt, woher diese Anliegen kommen.

Die Anatomie einer Entscheidung

Eine Architekturentscheidung ist mehr als ihr Ergebnis. Eine Entscheidung, die sich erklären, prüfen und überdenken lässt, hat sechs Teile, und sie zu benennen ist der erste Schritt zu guten Entscheidungen.

Kontext: die wirkenden Kräfte. Das zu lösende Problem, die Anforderungen an Qualitätsmerkmale, die es betreffen, die Randbedingungen (Budget, Fristen, Vorschriften, bestehende Systeme, Fähigkeiten des Teams) und die getroffenen Annahmen. Optionen: mindestens zwei echte Alternativen, oft einschließlich „nichts tun“ oder „aufschieben“. Eine Entscheidung, bei der nur eine Option betrachtet wurde, ist eine Ankündigung, keine Entscheidung. Kriterien: wie die Optionen beurteilt werden, abgeleitet aus den Anliegen der Stakeholder und nach Wichtigkeit gewichtet. Entscheidung und Begründung: die gewählte Option und, ganz wesentlich, warum sie die anderen bei den Kriterien geschlagen hat. Konsequenzen: was leichter wird, was schwerer wird, welche neuen Risiken entstehen und welche künftigen Optionen nun verschlossen sind. Status: vorgeschlagen, akzeptiert, veraltet oder abgelöst, dazu, wer die Entscheidung wann getroffen hat.

Die Konsequenzen verdienen besondere Aufmerksamkeit, denn an ihnen wird die Ehrlichkeit geprüft. Jede Option hat Nachteile; wer sie aufschreibt, schützt das Team vor Überraschungen und gibt der nächsten Person, die entscheidet, eine faire Darstellung. Die Konsequenzen einer Entscheidung werden zudem Teil des Kontexts für die nächste: Sobald Sie sich für asynchrones Messaging entschieden haben, müssen Sie entscheiden, wie Sie mit doppelten und in falscher Reihenfolge eintreffenden Nachrichten umgehen.

Einwegtüren und Zweiwegtüren

Die nützlichste einzelne Eigenschaft einer Entscheidung ist ihre Umkehrbarkeit: wie billig und sicher sie sich rückgängig machen lässt. In seinem Brief an die Amazon-Aktionäre von 2015 unterschied Jeff Bezos Entscheidungen vom Typ 1, die folgenreich und unumkehrbar oder nahezu unumkehrbar sind („Einwegtüren“), von Entscheidungen vom Typ 2, die änderbar und umkehrbar sind („Zweiwegtüren“). Typ-1-Entscheidungen verdienen langsame, sorgfältige Abwägung und Beratung. Typ-2-Entscheidungen sollten schnell von Einzelnen oder kleinen Gruppen mit gutem Urteilsvermögen getroffen werden, denn wenn sie sich als falsch erweisen, können Sie durch die Tür zurückgehen. Er warnte, dass große Organisationen dazu neigen, den schwerfälligen Typ-1-Prozess auf alles anzuwenden, was sie langsam und zaghaft macht.

Die Idee lässt sich direkt auf Architektur übertragen. Eine Einwegtür in Software ist eine Entscheidung, deren Rücknahme erfordern würde, große Teile des Systems neu zu schreiben, große Datenmengen zu migrieren, Verträge neu zu verhandeln oder viele Menschen umzuschulen: die Hauptprogrammiersprache einer großen Codebasis, das Datenmodell eines System of Record, die öffentliche API, an die Hunderte von Partnern angebunden sind, eine mehrjährige Cloud-Verpflichtung. Zu den Zweiwegtüren gehören die Wahl einer Logging-Bibliothek hinter Ihrer eigenen Schnittstelle, die interne Struktur eines Moduls, das Tuning eines Caches oder die Frage, welches von zwei gleichwertigen Nachrichtenformaten innerhalb eines Service verwendet wird.

Zwei Vorbehalte. Erstens ist Umkehrbarkeit ein Spektrum, nicht binär: Die meisten Entscheidungen liegen irgendwo zwischen „trivial rückgängig zu machen“ und „unmöglich rückgängig zu machen“, und die Kosten einer Umkehr wachsen meist, je mehr Code, Daten und Menschen von der Entscheidung abhängig werden. Eine Entscheidung, die im ersten Monat eine Zweiwegtür ist, kann im zwölften Monat zur Einwegtür geworden sein. Zweitens können Sie oft durch Design beeinflussen, vor welcher Art von Tür Sie stehen, wie der Abschnitt zur Umkehrbarkeit weiter unten zeigt.

Der Zeitpunkt: der Last Responsible Moment

Wann sollte eine Entscheidung getroffen werden? Mary und Tom Poppendieck machten in Lean Software Development: An Agile Toolkit (2003) die Idee populär, im Last Responsible Moment zu entscheiden: in dem Moment, in dem eine ausbleibende Entscheidung eine wichtige Alternative zunichtemachen würde. Vor diesem Moment entscheiden Sie mit weniger Informationen, als Sie haben könnten; danach wird die Entscheidung stillschweigend für Sie getroffen, meist schlecht.

Das Prinzip wirkt in beide Richtungen. Es spricht dagegen, zu früh zu entscheiden: Die Datenbanktechnologie in der ersten Woche festzulegen, bevor Sie die Struktur der Daten und die Zugriffsmuster verstehen, ist Raten. Ebenso spricht es dagegen, zu spät zu entscheiden. Hat das Team bereits begonnen, Persistenzcode auf Grundlage einer unausgesprochenen Annahme zu schreiben, ist die Entscheidung schon gefallen, nur nicht bewusst. Braucht der Einkauf sechs Wochen, um einen Cloud-Anbieter zu genehmigen, liegt der Last Responsible Moment für diese Wahl mindestens sechs Wochen vor dem Zeitpunkt, zu dem Sie die Umgebung brauchen.

Fachleute sind sich uneinig, wie weit man das treiben sollte. Kritiker weisen darauf hin, dass der „Last Responsible Moment“ leicht als Freibrief zum Aufschieben missbraucht wird, dass manche Entscheidungen (Teamstruktur, Programmiersprache) alles Weitere prägen und deshalb früh fallen müssen und dass Unentschlossenheit ihre eigenen Kosten hat: Ohne vereinbarte Schnittstellen können Teams nicht parallel arbeiten. Befürworter entgegnen, das Prinzip habe nie „so spät wie möglich“ bedeutet, sondern „so spät, wie es verantwortbar ist“, und den Moment zu bestimmen sei selbst ein Akt der Planung. Beide Seiten sind sich im praktischen Kern einig: Wissen Sie, welche Entscheidungen anstehen, wissen Sie, wann jede fallen muss, und nutzen Sie die Zeit bis dahin, um zu lernen.

Design für Umkehrbarkeit

Der billigste Weg, eine schwere Entscheidung zu treffen, ist oft, sie in eine leichtere zu verwandeln. Mehrere Techniken senken die Kosten, später umzudenken, um den Preis von etwas Aufwand jetzt.

Abstraktion an der Grenze. Setzen Sie eine schmale eigene Schnittstelle zwischen Ihre Kernlogik und eine Technologie, die Sie vielleicht ersetzen, etwa einen Zahlungsanbieter, einen Message Broker oder die API eines großen Sprachmodells. Ein späterer Austausch der Technologie betrifft dann einen Adapter statt der ganzen Codebasis. Die Idee geht auf David Parnas’ Information Hiding (1972) zurück und taucht in der hexagonalen Architektur (Kapitel 5) wieder auf. Feature-Flags. Liefern Sie neues Verhalten ausgeschaltet aus, schalten Sie es für einen kleinen Teil der Nutzer ein und in Sekunden wieder aus, wenn es sich falsch verhält; das macht Releases zu Zweiwegtüren. Schrittweise Migration. Lassen Sie Alt und Neu nebeneinander laufen und verlagern Sie den Traffic nach und nach, statt in einem Schritt umzuschalten. Spikes und Proofs of Concept. Investieren Sie ein paar Tage, um den riskantesten Teil mit einer Kandidatentechnologie zu bauen, bevor Sie sich festlegen. Vertragliche Ausstiege. Bevorzugen Sie kürzere Bindungen, Standarddatenformate und die Möglichkeit, Ihre Daten zu exportieren.

Das ist Optionsdenken, entlehnt aus der Finanzwelt: Sie zahlen jetzt eine kleine Prämie (einen Adapter, ein Flag, einen Spike), um das Recht, aber nicht die Pflicht zu erwerben, später den Kurs zu ändern. Wie jede Option lohnt sie sich nur, wenn die Prämie im Verhältnis zum Wert der Flexibilität klein ist. Jede Bibliothek „für den Fall, dass wir sie wechseln“ in eine Abstraktion zu hüllen, ist ein klassischer Weg, Kosten und Indirektion für eine Flexibilität hinzuzufügen, die niemand nutzt. Kaufen Sie Optionen für Entscheidungen, die sowohl unsicher als auch teuer umzukehren sind; bei allen anderen entscheiden Sie und machen weiter.

Kognitive Fallen

Architektinnen und Architekten sind Menschen, und Architekturentscheidungen fallen unter Unsicherheit, Zeitdruck und sozialem Druck: ideale Bedingungen für kognitive Verzerrungen. Wer die häufigsten beim Namen kennt, erkennt sie leichter bei sich selbst und kann sie bei anderen freundlich hinterfragen.

Entscheidungen festhalten: ein Ausblick auf ADRs

Das zweite Gesetz besagt, dass das Warum wichtiger ist als das Wie, also muss das Warum aufgeschrieben werden. Das am weitesten verbreitete schlanke Format ist das Architecture Decision Record (ADR), das Michael Nygard 2011 in einem Blogbeitrag vorgeschlagen hat. Ein ADR ist eine kurze Textdatei, die mit dem Code in der Versionsverwaltung liegt und eine Entscheidung nach der oben beschriebenen Anatomie festhält: Titel, Status, Kontext, Entscheidung und Konsequenzen. ADRs werden nie bearbeitet, um die Geschichte zu ändern; eine spätere Entscheidung löst eine frühere ab und verweist auf sie, sodass das Protokoll erzählt, wie sich die Architektur entwickelt hat.

Kapitel 4 behandelt Vorlagen, Werkzeuge und die Gewohnheiten, die ADRs nützlich halten, in Architecture Decision Records. Das folgende Beispiel hält die Entscheidung aus dem ausgearbeiteten Beispiel fest.

ADR 7: Use managed PostgreSQL for the order service

Status: Accepted (2026-10-12)

Context
Orders and payments need multi-row transactions and must never be lost.
The team knows PostgreSQL well and has no database administrator.
Expected growth is about 3x in two years.

Decision
We will use the cloud provider's managed PostgreSQL service.

Consequences
+ Backups, patching and failover are handled by the provider.
+ Standard SQL keeps self-hosting or another provider open as a fallback.
- Monthly cost is about 30% higher than self-hosting at current load.
- Maintenance windows are set by the provider.
Revisit if write volume exceeds what one primary instance can handle.