Leichtgewichtige Reviews und Risk-Storming

Warum schwergewichtige Review-Gremien oft scheitern

Viele Organisationen steuern Architektur über ein Architecture Review Board: ein Gremium erfahrener Architekten, das monatlich tagt, einen Foliensatz oder ein langes Dokument erhält und Entwürfe genehmigt oder ablehnt. Die Absicht ist vernünftig: unabhängige, erfahrene Augen auf wesentliche Entscheidungen. Die Ergebnisse sind oft schlecht, aus Gründen, die strukturell und nicht persönlich sind.

Das erste Problem ist der Zeitpunkt. Ein Gremium, das zu festen Zeitpunkten tagt, sieht einen Entwurf entweder zu früh (noch ist nichts entschieden) oder, weit häufiger, zu spät, wenn das Team schon einen Prototyp gebaut, sich an einen Anbieter gebunden und einen Termin zugesagt hat. Eine Ablehnung ist dann so teuer, dass das Gremium unter Auflagen genehmigt, die niemand nachverfolgt. Das zweite ist der Kontext: Reviewer, die eine Stunde mit einem System verbringen, das sie nie gesehen haben, stellen allgemeine Fragen und übersehen die konkreten Risiken, die die eigenen Entwickler, Betriebs- und Sicherheitsfachleute des Teams in Minuten nennen könnten. Das dritte sind die Anreize: Wenn ein Review eine Prüfung ist, präsentieren Teams den Entwurf, den sie genehmigt haben wollen, nicht ihre Zweifel, und das Gremium erfährt wenig. Das vierte ist die Warteschlange: Eine monatliche Sitzung mit voller Tagesordnung fügt jeder wesentlichen Entscheidung Wochen des Wartens hinzu und verleitet Teams dazu, das Gremium zu umgehen, indem sie Entscheidungen als geringfügig deklarieren.

Das alles heißt nicht, dass unabhängige Reviews wertlos sind. Regulierte Branchen (Banken, Gesundheitswesen, Luftfahrt) brauchen oft eine dokumentierte Freigabe, und manche Entscheidungen brauchen tatsächlich die Autorität eines leitenden Gremiums. Die Lehre ist, dass Reviews häufig, früh, gemeinsam und risikoorientiert sein sollten, wobei eine formale Genehmigung den wenigen Entscheidungen vorbehalten bleibt, die sie wirklich erfordern. Abschnitt 11.4 greift auf, wie Governance ohne langsame Gates funktionieren kann.

Was ein gutes leichtgewichtiges Review leistet

Ein leichtgewichtiges Review ist eine kurze, strukturierte Sitzung, typischerweise ein bis zwei Stunden, in der die Menschen, die einen Entwurf am besten kennen, und einige, die ihn mit frischem Blick sehen, gemeinsam nach Risiken suchen. Es zielt auf vier Dinge: Risiken entdecken, solange sie günstig zu beheben sind, ein gemeinsames Verständnis des Entwurfs im Team aufbauen, die Annahmen des Architekten unabhängig hinterfragen und eine Aufzeichnung der akzeptierten, abgemilderten oder verworfenen Risiken hinterlassen. Sein Ergebnis ist eine priorisierte Risikoliste mit Verantwortlichen, kein Urteil.

Mehrere Techniken passen zu dieser Beschreibung. Sie unterscheiden sich darin, was sie untersuchen (ein Diagramm, einen Plan, ein Dokument oder ein laufendes System) und worin sie am besten sind, und sie lassen sich gut kombinieren.

Risk-Storming

Risk-Storming ist eine visuelle, kollaborative Technik von Simon Brown, dem Urheber des C4-Modells (Abschnitt 4.3). Sie beruht auf einer einfachen Beobachtung: Verschiedene Menschen sehen verschiedene Risiken, und am besten sammelt man sie, indem man alle vor dieselben Diagramme stellt und sie bittet, unabhängig hinzusehen, bevor diskutiert wird. Sie hat vier Schritte.

1. Die Architektur zeichnen. Hängen Sie Diagramme dessen auf, was Sie bauen oder ändern wollen, idealerweise auf mehr als einer Ebene: Ein Systemkontextdiagramm und ein Containerdiagramm genügen meist, dazu ein Komponentendiagramm für den riskantesten Container. 2. Risiken einzeln identifizieren. Alle Beteiligten schreiben etwa zehn Minuten lang schweigend je ein Risiko pro Haftnotiz, mit kurzer Beschreibung und Priorität. Das Schweigen ist wichtig: Es verhindert, dass die erste oder ranghöchste Stimme alle anderen verankert, und genau so verlieren Gruppendiskussionen am häufigsten Information. 3. Die Risiken auf den Diagrammen zusammenführen. Alle kleben ihre Notizen auf den Teil des Diagramms, den das Risiko betrifft. Sofort entstehen Häufungen, und das Diagramm wird zur Heatmap. 4. Besprechen und zusammenfassen. Die Gruppe bespricht die Häufungen und achtet dann besonders auf zwei Arten von Notizen: Risiken, die nur eine Person genannt hat (oft jemand mit Wissen, das anderen fehlt, etwa der Support-Engineer), und Risiken, denen verschiedene Personen sehr unterschiedliche Prioritäten gegeben haben (ein Zeichen für ein Missverständnis). Vereinbarte Risiken kommen mit Verantwortlichen in ein Risikoregister; Punkte, die man übereinstimmend nicht als Risiko einstuft, werden ebenfalls festgehalten.

Die Priorität wird meist als Wahrscheinlichkeit mal Auswirkung bewertet, jeweils niedrig (1), mittel (2) oder hoch (3), was Werte von 1 bis 9 ergibt. Browns Leitfaden teilt sie ein in hoch (6 oder 9), mittel (3 oder 4) und niedrig (1 oder 2), üblicherweise dargestellt mit rosa oder roten, gelben oder orangefarbenen und grünen Notizen. Eine Liste von Denkanstößen hilft, über das eigene Fachgebiet hinauszudenken: Skalierbarkeit, Verfügbarkeit, Performance, Sicherheit, Datenkonsistenz, Abhängigkeiten von Drittanbietern, Kosten, technologische Reife, Fähigkeiten des Teams sowie Auslieferung und Betrieb.

Pre-Mortems

Risk-Storming betrachtet eine Struktur. Ein Pre-Mortem betrachtet einen Plan. Gary Klein beschrieb es im September 2007 in der Harvard Business Review. Eine Obduktion erklärt, warum ein Patient gestorben ist, was allen hilft außer dem Patienten; ein Pre-Mortem findet statt, bevor das Projekt beginnt, wenn die Antworten seinen Kurs noch ändern können.

Das Vorgehen ist kurz. Die Leitung erläutert der Gruppe den Plan oder die Entscheidung und verkündet dann, es sei jetzt einige Monate später und das Vorhaben sei gescheitert, und zwar gründlich. Alle schreiben einige Minuten lang unabhängig voneinander jeden Grund auf, der ihnen für das Scheitern einfällt. Dann geht die Leitung reihum und sammelt jeweils einen Grund, bis die Listen erschöpft sind, und die verantwortliche Person des Plans prüft sie auf Möglichkeiten, ihn zu stärken. Klein zitiert Forschung von Deborah Mitchell, Jay Russo und Nancy Pennington (1989), wonach die Vorstellung, ein Ereignis sei bereits eingetreten (prospektive Rückschau), die Fähigkeit, Gründe für künftige Ergebnisse zu erkennen, um etwa 30 % steigert. Die Rahmung verändert auch die soziale Dynamik: Die Frage ist nicht mehr, ob der Plan scheitern könnte, was illoyal klingt, sondern warum er gescheitert ist, was zur Kreativität einlädt.

In der Architektur sind Pre-Mortems besonders vor großen Festlegungen nützlich: bei der Einführung eines ereignisgesteuerten Stils, der Migration in eine neue Cloud, der Ablösung eines Altsystems (Abschnitt 11.6) oder der Einführung einer Plattform. Typische Ergebnisse, die ein diagrammbasiertes Review übersehen würde, sind ein Team ohne Erfahrung mit der neuen Technologie, eine Migration, die auf halbem Weg stecken bleibt und zwei Systeme zu betreiben hinterlässt, ein wichtiger Lieferant, der seine Preise ändert, und ein Geschäft, das die Geduld verliert, bevor sich Nutzen zeigt.

Architektur-Katas

Architektur-Katas wurden von Ted Neward, inspiriert von Dave Thomas’ Code-Katas, als Übungen für Architekten geschaffen. Eine Kata ist eine kurze Aufgabenstellung für ein fiktives System (einige Absätze zu Anforderungen, Nutzern und Randbedingungen, bewusst unvollständig). Kleine Teams von drei bis fünf Personen bearbeiten sie für eine feste Zeit, befragen eine Moderation, die den Kunden spielt, um fehlende Anforderungen aufzudecken, skizzieren dann eine Architektur und stellen sie den anderen Teams vor, die sie hart, aber fair hinterfragen, bevor der Raum abstimmt. Neal Ford pflegt eine öffentliche Sammlung von Katas, und O’Reilly hat Wettbewerbe mit Architektur-Katas veranstaltet.

Katas sind keine Reviews eines realen Entwurfs, tragen aber auf zwei Weisen zur Review-Kultur bei. Sie schulen die Fähigkeit, einen Entwurf unter Befragung zu erklären und zu verteidigen und gute Fragen zum Entwurf anderer zu stellen, genau das, was leichtgewichtige Reviews brauchen. Und eine interne Kata zu einem realen anstehenden Problem, bei der zwei oder drei Teams unabhängig entwerfen, ist ein günstiger Weg, den Lösungsraum vor einer Festlegung zu erkunden: Wenn drei Teams drei verschiedene Entwürfe liefern, zeigen die Unterschiede, wo die echten Abwägungen liegen.

TARA und checklistenbasierte Reviews

Reviews bestehender Systeme stehen vor einem anderen Problem: Die gebaute Architektur kann von der beschriebenen abweichen, und die Belege sind über Personen, Dokumente, Code und Produktionsdaten verstreut. Eoin Woods, Mitautor von Software Systems Architecture, beschrieb 2011 den Tiny Architectural Review Approach (TARA) als bewusst leichtgewichtige, praxistaugliche Alternative zu szenariolastigen Methoden. Eine kleine Zahl von Reviewern erhebt die wichtigsten Anforderungen und den Kontext des Systems, ermittelt seine tatsächliche Struktur, beurteilt seine Implementierung mit automatisierter Analyse (Modulabhängigkeiten, Größe, Code-Metriken, Testabdeckung) neben Laufzeitinformationen wie Logs, verknüpft das Gefundene mit Expertenurteil mit den Anforderungen und präsentiert Ergebnisse und Empfehlungen in einer vorab festgelegten Form. Seine Stärke sind Tempo und Belege; seine Schwäche, die Woods selbst einräumte, ist die Abhängigkeit von der Expertise der Reviewer.

Checklisten ergänzen jede Technik. Eine Checkliste findet allein keine Risiken, verhindert aber, dass ein Review eine ganze Kategorie vergisst (Wiederherstellung aus Backups, Secrets, Kosten im großen Maßstab), nur weil niemand im Raum zufällig daran gedacht hat. Halten Sie Checklisten kurz, zugeschnitten auf die Vorfallgeschichte Ihrer Organisation, und formulieren Sie sie als Fragen, die Belege verlangen statt Ja-oder-Nein-Antworten.

Designdokumente und RFC-Reviews

Abschnitt 4.8 hat Designdokumente und RFCs als Weg beschrieben, eine Änderung schriftlich vorzuschlagen, bevor sie gebaut wird. Sie gut zu reviewen ist eine eigene Fähigkeit. Ein schriftliches Review hat echte Vorteile gegenüber einer Besprechung: Reviewer kommentieren, wenn sie Zeit zum Nachdenken haben, Kolleginnen und Kollegen aus der Ferne und stillere Teammitglieder tragen gleichberechtigt bei, und die Kommentare werden zur Aufzeichnung. Typische Fehlschläge sind Dokumente, die niemand liest, Kommentar-Threads, die nie abgeschlossen werden, und Reviews, die zu einem inoffiziellen Gate werden.

Gute Praxis ist, oben die gesuchte Entscheidung und die Kommentarfrist zu nennen; die Reviewer zu benennen, deren Beitrag erforderlich ist (Sicherheit, Betrieb, die Verantwortlichen betroffener Services), und alle anderen einzuladen; die Reviewer zu bitten, jeden Kommentar als Frage, Vorschlag oder blockierenden Einwand zu kennzeichnen, damit der Autor weiß, welche gelöst werden müssen; gegen die Qualitätsszenarien und die Checkliste unten zu reviewen, nicht nach persönlichem Geschmack; nur für ungelöste Einwände eine kurze Besprechung anzusetzen; und die wesentlichen Entscheidungen als ADRs festzuhalten. In Organisationen mit Advice Process (Abschnitt 11.4) ist der RFC das Mittel, um Rat einzuholen, und die Entscheidung bleibt beim Autor.