Warum gute Architektur in Produktion trotzdem scheitert

Dieser Beitrag basiert auf dem Artikel „Why Good Architecture Still Fails in Production” von Ivan Pelivanovic auf ShiftMag, der ein Interview mit Eoin Woods auf der Devoxx UK zusammenfasst. Den englischen Originaltext findest du unter shiftmag.dev.

Eoin Woods ist Co-Autor dreier Bücher über Software-Architektur und ehemaliger CTO von Endava. Er arbeitet seit Jahrzehnten mit großen Systemen. Die Ausfälle, die er immer wieder beobachtet, sind selten spektakulär. Sie beginnen mit etwas Banalem: 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)

• Produktion macht Annahmen sichtbar: Diagramme, Reviews und Slide Decks schützen nicht vor ungeprüften Annahmen über die reale Umgebung.
• Kopplung zeigt sich erst unter Last: Komponenten, die isoliert funktionieren, können das Gesamtsystem in den Stillstand ziehen, wenn ihre Abhängigkeiten nicht als Interaktionen verstanden werden.
• Szenarien decken Wissenslücken auf: Konkrete Szenarien wie „Was passiert bei 5.000 gleichzeitigen Nutzern und Datenbankausfall um 19 Uhr?” erzwingen die Fragen, die sonst erst nach dem Incident gestellt werden.
• ADRs machen implizite Entscheidungen explizit: Architektur-Entscheidungen aufschreiben ist seit den 1990er Jahren bewährt und trotzdem selten konsequent umgesetzt.
• KI verschärft das Problem: Mehr automatisch generierter Code bedeutet mehr versteckte Annahmen, die niemand geprüft hat.

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

Eoin Woods trennt bewusst nicht zwischen elegantem Entwurf und chaotischer Umsetzung. 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 ist nie nur 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.

Woods sagt dazu: In mission-critical Systemen sind wir deutlich weniger begeistert von „Move fast, break things and fix forward”, 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. Architektur ist deshalb nie nur Struktur. Sie handelt von Konsequenzen. Ein Entwurf, der in einer Präsentation effizient aussieht, kann in der realen Welt teuer werden, 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

Woods beschreibt 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?

Woods bringt den Wert dieser Übung auf den Punkt: Es gibt nichts Besseres als das Schreiben eines Szenarios, um herauszufinden, was man über das eigene System nicht weiß.

Er beschreibt 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 von Woods 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.

Wie gehst du aktuell mit impliziten Annahmen in deiner Architektur um, und hast du einen Prozess, der sie vor dem Deployment sichtbar macht?