Warum gute Architektur in Produktion trotzdem scheitert

Eoin Woods, Co-Autor dreier Architektur-Bücher und ehemaliger CTO von Endava, arbeitet seit Jahrzehnten mit großen Systemen. Die Ausfälle, die ihm dabei begegnen, beginnen selten mit einem dramatischen Fehler. Sie beginnen mit einer Umgebungsvariable, die niemand verifiziert hat, einer Technologie, die niemand vollständig verstanden hat, oder einem Seiteneffekt, den niemand erwartet hat, bis das System live war.

Key Takeaways (TL;DR)

• Prüfe Annahmen vor der Produktion, nicht danach: Diagramme und Reviews validieren den Entwurf, nicht die reale Umgebung.
• Analysiere Kopplung auf Laufzeitebene: Isoliert funktionierende Komponenten können das Gesamtsystem unter Last lahmlegen.
• Übersetze vage Anforderungen in konkrete Szenarien: Statt „skalierbar” frage, was bei spezifischer Last und spezifischem Ausfall passiert.
• Schreibe ADRs für jede strukturelle Entscheidung: Eine Gewohnheit aus den 1990ern, die bis heute kaum ein Team konsequent pflegt.
• Behandle KI-generierten Code als zusätzliche Annahmenquelle: Mehr Code in kürzerer Zeit bedeutet mehr ungeprüfte Annahmen pro Release.

Basiert auf „Why Good Architecture Still Fails in Production” von Ivan Pelivanovic, einem Devoxx-UK-Interview mit Eoin Woods. Das Original findest du hier: shiftmag.dev

Das System, das zählt, ist das in Produktion

Die Trennung zwischen elegantem Entwurf und chaotischer Umsetzung führt in die Irre. Das System, das zählt, ist das, das ausgeliefert wird, und das steckt voller Annahmen.

Das Diagramm kann sauber aussehen, das Architecture Review kann bestanden werden und das Slide Deck kann überzeugend klingen. Produktion ist der Ort, an dem die Annahmen sichtbar werden. Erfahrung verändert, was Menschen bemerken. Woods formuliert das so: Je älter und zynischer man wird, desto mehr Fragen stellt man.

Seniorität in der Architektur bedeutet oft, die fehlende Frage zu bemerken, bevor die fehlende Antwort zu einem Incident wird. Dieselbe Logik gilt für gekoppelte Systeme. Eine Komponente kann isoliert einwandfrei funktionieren und trotzdem Probleme verursachen, sobald der Rest des Systems auf sie reagiert.

Wenn eine Komponente dramatisch langsamer wird, werden die anderen (sofern eng gekoppelt) ebenfalls dramatisch langsamer. Erst wenn es passiert, bemerken alle, dass alles im Gleichschritt langsamer wird, weil niemand verstanden hat, wie stark die Kopplung tatsächlich war.

Das ist die Art von Fehler, die Teams erst im Nachhinein verstehen. Das System verhält sich wie entworfen und versagt trotzdem als Ganzes, weil die Interaktionen nie als Interaktionen verstanden wurden. Wer das Adapter-Port-Pattern konsequent einsetzt, reduziert diese unsichtbare Kopplung zumindest auf der Ebene externer Abhängigkeiten. Aber Kopplung zwischen internen Komponenten erfordert ein tieferes Verständnis der Laufzeitabhängigkeiten, das kein Pattern automatisch liefert.

Architektur handelt von Konsequenzen, nicht nur von Struktur

Diese Unterscheidung wird dort am wichtigsten, wo Recovery teuer ist. Finanzinfrastruktur, Gesundheitswesen, industrielle Steuerungssysteme. Diese Umgebungen haben nicht den Luxus, Ausfälle als Lernübung zu behandeln.

In mission-critical Systemen ist die Begeisterung für „Move fast, break things and fix forward” deutlich geringer, weil ein tatsächlicher Bruch ernsthafte Konsequenzen hat.

Geschwindigkeit hilft nur, wenn Recovery billig ist. Wenn Rollback schwierig ist, Reparatur langsam und der Impact irreversibel, dann hört schnelle Delivery auf, eine Tugend zu sein, und wird zur Gefahr. Ein Entwurf, der in einer Präsentation effizient aussieht, wird teuer, sobald seine Annahmen auf ein System treffen, das keine Fehler absorbieren kann.

Das ist auch der Grund, warum Vibe-Coding ohne Architekturkontrolle in kritischen Systemen besonders gefährlich ist. KI-generierter Code optimiert auf den kürzesten Weg zum funktionierenden Feature. Die Konsequenzen eines Fehlers in Produktion sind in diesem Optimierungsziel nicht enthalten.

Szenarien erzwingen die fehlenden Fragen

Eine Szene, die fast jeder Ingenieur kennt: Ein Stakeholder fragt nach etwas Skalierbarem, Kosteneffizientem, Sicherem und Einfachem. Der Architekt kommt mit containerisierten Microservices, geringeren Speicherkosten, erzwungenen Passwort-Änderungen und einem task-orientierten Interface zurück. Der Stakeholder sagt, das klingt gut. Keiner von beiden hat wirklich verstanden, was gefragt oder entschieden wurde.

Genau diese Lücke zwischen dem, was gefragt wurde, und dem, was verstanden wurde, sollen Architektur-Szenarien schließen.

Ein Szenario nimmt einen vagen Wunsch und macht ihn konkret. Nicht „das System soll skalierbar sein”, sondern: Was passiert, wenn 5.000 Nutzer gleichzeitig verbunden sind und die primäre Datenbank um 19 Uhr während der Spitzenlast ausfällt? Nicht „die App soll sicher sein”, sondern: Was passiert, wenn ein Entschlüsselungsschlüssel nach einem Incident wiederhergestellt werden muss?

Es gibt nichts Besseres als das Schreiben eines Szenarios, um herauszufinden, was man über das eigene System nicht weiß.

Sechs praktische Anwendungsfälle für Szenarien: Teams nutzen sie, um:

1. zu entscheiden, was gebaut werden soll
2. Entwurfsoptionen zu vergleichen
3. gezielte Recherche zu betreiben
4. Designentscheidungen breiter zu bewerten
5. das Verhalten bestehender Systeme zu erklären, ohne sich in technischen Details zu verlieren
6. Fragen aufzudecken, die viel früher hätten gestellt werden sollen

Der Punkt ist nicht Dokumentation um ihrer selbst willen. Es geht darum, das System lesbar zu machen, bevor Produktion die Erklärung übernimmt. Wenn ein Offline-Modus nur demonstriert, aber nie gegen das Live-System getestet wurde, wird das im Szenario offensichtlich. Wenn ein Recovery-Flow hauptsächlich in einer Vendor-Demo existiert, macht das Szenario aus der Demo eine Frage statt einer Schlussfolgerung.

ADRs: Die einfachste nützliche Gewohnheit

Der praktischste Rat ist gleichzeitig der am wenigsten glamouröse: Architektonische Entscheidungen bewusst treffen und aufschreiben.

Das bedeutet: die Annahmen dokumentieren, die in einer Entscheidung stecken, die Trade-offs, die sie akzeptiert, und die Implikationen, die daraus folgen.

Architecture Decision Records (ADRs) sind keine neue Idee. Woods schrieb sie bereits als Berufseinsteiger in den 1990er Jahren. Selbst damals waren sie nicht gängige Praxis. Die Tatsache, dass der Rat alt ist, macht ihn nicht weniger relevant. Eher das Gegenteil.

KI-Tools generieren Code schneller, als Teams die darin enthaltenen Annahmen prüfen können. Anforderungen sind weiterhin vage. Stakeholder verstehen die technische Antwort oft nicht vollständig. Entscheidungen werden weiterhin zu oft implizit gelassen.

Das Ergebnis ist mehr Software mit mehr versteckten Annahmen darin.

Genau dort beginnt Architektur wirklich: in dem Teil der Arbeit, der diese Annahmen sichtbar macht, bevor Produktion es tun muss.

Checkliste: Versteckte Annahmen in der eigenen Architektur aufdecken

1. Architektur-Szenarien für jede Quality-Attribute-Anforderung schreiben. „Skalierbar” oder „sicher” reicht nicht. Jede nicht-funktionale Anforderung braucht ein konkretes Szenario mit Zahlen, Zeitpunkt und Ausfallbedingung. Wenn das Szenario nicht geschrieben werden kann, ist die Anforderung nicht verstanden.
2. ADRs für jede strukturelle Entscheidung anlegen. Jede Entscheidung über Technologiewahl, Kopplung, Datenfluss oder Deployment-Strategie braucht ein ADR mit Kontext, Annahmen, Trade-offs und Konsequenzen. Ein ADR-Template mit genau diesen vier Feldern reicht aus.
3. Kopplungsanalyse auf Laufzeitebene durchführen. Statische Abhängigkeiten in der Codebasis zeigen nicht, was unter Last passiert. Circuit Breaker, Timeouts und Fallbacks für jede synchrone Kommunikation zwischen Diensten definieren. Dann testen, ob der Fallback tatsächlich funktioniert.
4. Recovery-Kosten vor dem Deployment bewerten. Vor jedem Release die Frage stellen: Was passiert, wenn dieses Deployment fehlschlägt? Wenn Rollback schwierig, langsam oder unmöglich ist, ist die Deployment-Strategie das eigentliche Risiko, nicht der Code.
5. KI-generierten Code auf implizite Annahmen prüfen. Jede automatisch generierte Architekturentscheidung (Technologiewahl, Datenbankschema, API-Design) explizit in einem ADR festhalten. Wenn die KI die Entscheidung getroffen hat, heißt das nicht, dass sie bewusst getroffen wurde.

Architektur beginnt nicht beim Zeichnen von Boxen, sondern beim Sichtbarmachen der Annahmen, die Produktion sonst auf die harte Tour aufdeckt.