Architektur für verschiedene Zielgruppen kommunizieren

Kommunikation ist die Aufgabe

Eine Architektur, die nur ihr Architekt versteht, ist gescheitert, wie gut sie auch sein mag. Entscheidungen prägen, was Dutzende Menschen bauen, betreiben, finanzieren und prüfen, und sie funktionieren nur, wenn diese Menschen sie gut genug verstehen, um danach zu handeln und zu bemerken, wenn die Wirklichkeit davon abweicht. Deshalb zählt der iSAQB-Lehrplan die Kommunikation der Architektur zu den Kernaufgaben einer Architektin oder eines Architekten, und deshalb hängt die Architektenrolle aus Kapitel 1 so stark von zwischenmenschlichen Fähigkeiten ab.

Die früheren Abschnitte dieses Kapitels haben das Material geliefert: Sichten, C4- und UML-Diagramme, ADRs, eine arc42-Struktur und eine Pipeline, die alles aktuell hält. In diesem Abschnitt geht es darum, dieses Material mit Menschen zu nutzen. Die Kernfähigkeit ist überall dieselbe: Entscheiden Sie, wer die Zielgruppe ist, was sie tun muss, nachdem sie Sie gehört hat, und geben Sie ihr genau das, was dafür nötig ist, in einer Form, die sie aufnehmen kann. Gregor Hohpes Bild vom Architect Elevator (The Software Architect Elevator, 2020) fasst die Bandbreite: Ein Architekt fährt zwischen der Vorstandsetage, wo Strategie in geschäftlichen Begriffen festgelegt wird, und dem Maschinenraum, wo Systeme gebaut werden, und muss auf jeder Etage verstanden werden.

Auf die Zielgruppe zuschneiden

Jede Zielgruppe hat ihre eigenen Anliegen, genau im Sinne von Stakeholder und Anliegen, und ihr eigenes Vokabular und ihre eigene Aufmerksamkeitsspanne. Die Tabelle ist ein Ausgangspunkt; die eigentliche Kunst besteht darin, vor jeder Vorbereitung zu fragen: Was wird diese Person nach diesem Gespräch entscheiden oder anders machen?

Zwei Gewohnheiten helfen bei jeder Zielgruppe. Beginnen Sie mit der Antwort. Beschäftigte Lesende sollten die Schlussfolgerung im ersten Satz erfahren, dann die stützenden Gründe, dann die Details; das ist die Struktur, die Barbara Minto Beratern als Pyramid Principle beigebracht hat, und es ist dieselbe Idee wie Fowlers umgekehrte Pyramide für ADRs. Verwenden Sie ihre Worte. Für eine Finanzdirektorin ist Eventual Consistency Rauschen; Das Restaurant sieht eine neue Bestellung bis zu zwei Sekunden nach dem Kunden, und nichts geht verloren ist eine Tatsache, die sie abwägen kann.

Abwägungen erklären

Die meiste Architekturkommunikation ist im Kern die Erklärung einer Abwägung. Laien misstrauen Empfehlungen, die keinen Nachteil zu haben scheinen, und das zu Recht. Eine klare, konsequent verwendete Struktur macht Abwägungen leicht nachvollziehbar: die Optionen (einschließlich Nichtstun), die Kriterien, die für diese Zielgruppe zählen, wie jede Option abschneidet, die Empfehlung und ihre Konsequenzen, einschließlich dessen, was Sie aufgeben. Das ist die Anatomie einer Entscheidung aus Kapitel 1 und der Inhalt eines ADR, umgeformt für Zuhörende.

Die einseitige Architekturübersicht

Jedes System profitiert von einer einseitigen Architekturübersicht: einer einzigen Seite, die neue Teammitglieder, Führungskräfte oder Reviewer aus einem anderen Team in fünf Minuten lesen können. Sie ersetzt nicht die vollständige Dokumentation, sondern ist ihre Eingangstür. Eine nützliche Struktur ist: was das System tut und für wen (zwei Sätze); die drei wichtigsten Qualitätsziele; ein Systemkontextdiagramm; ein Containerdiagramm oder eine Liste der wichtigsten Bausteine; die etwa fünf Entscheidungen, die alles prägen (je eine Zeile, mit Link zu den ADRs); die größten Risiken; und wo man mehr findet. Die arc42-lite-Seite in arc42 und Vorlagen ist eine solche Übersicht.

Die Disziplin, die Architektur auf eine Seite zu bringen, ist schon für sich wertvoll. Wenn sich die Hauptideen nicht auf einer Seite darstellen lassen, sind sie vermutlich auch dem Team nicht klar.

Storytelling: einer Anfrage folgen

Menschen merken sich Geschichten besser als Strukturen. Eine wirkungsvolle Technik, um ein beliebiges System zu erklären, ist es, einer Anfrage zu folgen: Wählen Sie ein einzelnes, konkretes, wichtiges Ereignis, etwa einen Kunden, der eine Bestellung aufgibt, und gehen Sie Schritt für Schritt durch, was damit quer durch die Architektur geschieht. Ein statisches Kastendiagramm zeigt, was existiert; die Geschichte zeigt, warum es existiert und wie die Teile zusammenarbeiten. Sie bringt auch die interessanten Momente ganz natürlich zum Vorschein: wo der Kunde wartet, wo Daten eine Vertrauensgrenze überschreiten, was passiert, wenn der Zahlungsanbieter langsam ist.

Wählen Sie die Geschichte passend zur Zielgruppe. Für Entwicklungsteams erst den Happy Path, dann einen Fehlerfall (jetzt läuft beim Zahlungsanbieter ein Timeout ab). Für den Betrieb den Ausfall und die Wiederherstellung. Für Führungskräfte das Kundenerlebnis mit nur den geschäftlich relevanten Momenten. Nummerieren Sie die Schritte im Diagramm, damit Sie darauf zeigen können, und lassen Sie dasselbe Diagramm auf dem Bildschirm, während Sie sprechen, statt zwischen Folien hin- und herzuspringen.

Gut am Whiteboard arbeiten und skizzieren

Viel Architekturkommunikation geschieht live, an einem Whiteboard oder auf einer gemeinsamen Online-Zeichenfläche, und ein paar Gewohnheiten machen Skizzen weit nützlicher. Sagen Sie, was Sie zeichnen, bevor Sie es zeichnen (Das ist die Container-Ebene: Dinge, die wir getrennt deployen), damit das Publikum die Abstraktionsebene kennt. Beginnen Sie mit dem Kontext: die Nutzer und externen Systeme am Rand, dann das Innere. Beschriften Sie jeden Kasten und jede Linie beim Zeichnen, einschließlich der Richtung und dessen, was fließt; ein unbeschrifteter Pfeil wird von drei Personen auf drei verschiedene Arten gelesen. Zeichnen Sie eine kleine Legende in eine Ecke, wenn Sie mehr als eine Art von Linie oder Kasten verwenden. Lassen Sie Platz, denn die besten Ideen kommen mitten in der Diskussion und brauchen einen Ort.

Skizzen sind Denkwerkzeuge und dürfen weggeworfen werden, die Schlussfolgerungen aber nicht. Fotografieren Sie das Whiteboard und machen Sie innerhalb eines Tages aus allem, was wichtig sein wird, ein richtiges Diagramm, ein ADR oder eine Änderung an der Dokumentation. Simon Brown, der das C4-Modell geschaffen hat, beobachtete, dass die Whiteboard-Diagramme vieler Teams gerade deshalb mehrdeutige Kästen und Linien sind, weil ihnen ein vereinbarter Satz von Abstraktionen fehlt; die C4-Ebenen am Whiteboard zu verwenden ist einer der einfachsten Wege, das zu beheben.

Designdokumente und RFCs

Viele Entwicklering-Organisationen verwenden ein schriftliches Designdokument, oft RFC (Request for Comments) genannt, um eine bedeutende Änderung vorzuschlagen, bevor sie gebaut wird. Der Name greift die RFC-Reihe des Internets auf, die im April 1969 mit RFC 1 von Steve Crocker begann. Die Autorin oder der Autor beschreibt das Problem, den Kontext, die Ziele und Nicht-Ziele, das vorgeschlagene Design, die erwogenen Alternativen und die übergreifenden Anliegen wie Sicherheit, Datenschutz und Observability; das Dokument wird an die Betroffenen verteilt, die schriftlich kommentieren; und es wird genehmigt oder überarbeitet. Malte Ubls viel gelesene Beschreibung von Design Docs bei Google (2020) nennt genau diese Abschnitte und schlägt zehn bis zwanzig Seiten für große Projekte und ein bis drei Seiten für kleine Mini Design Docs vor. Gergely Orosz beschrieb, wie Uber von seinen frühen Jahren an einen RFC-Prozess nutzte, um Wissen zu verbreiten und Probleme früh zu erkennen (2018).

Amazon treibt das Schreiben weiter: Sein Aktionärsbrief von 2017 erklärt, dass das Unternehmen in Meetings keine Folienpräsentationen verwendet, sondern narrativ strukturierte sechsseitige Memos, die die Teilnehmenden zu Beginn still lesen. Der gemeinsame Nutzen all dieser Praktiken ist, dass Schreiben klares Denken erzwingt, schriftliche Kommentare auch ruhigeren und entfernt arbeitenden Kollegen eine Stimme geben und das Dokument zu einer Aufzeichnung wird. Auch die Risiken sind gemeinsam: lange Dokumente, die niemand zu Ende liest, Review-Prozesse, die zu bürokratischen Hürden werden, und Design Docs, die nach der Umsetzung nie aktualisiert werden.

Design Docs und ADRs ergänzen sich. Ein Design Doc untersucht ein Problem und schlägt ein ganzes Design vor, das oft mehrere Entscheidungen umfasst; sobald es genehmigt ist, werden die bedeutenden Entscheidungen darin als ADRs festgehalten, die kürzer, dauerhaft und indexiert sind. Eine vernünftige Regel lautet: Design Doc zum Denken und Überzeugen, ADR zum Erinnern.

Bei einem Architektur-Review präsentieren

Ein Architektur-Review ist ein Meeting, in dem andere erfahrene Personen ein Design untersuchen, um Risiken zu finden, bevor sie teuer werden. Strukturierte Methoden wie ATAM und leichtgewichtigere Reviews werden in Kapitel 11: Leichtgewichtige Reviews behandelt; hier geht es darum, wie man gut präsentiert. Senden Sie das Material mindestens zwei Tage vorher: die einseitige Übersicht, die wichtigsten Diagramme, die relevanten ADRs und die Qualitätsszenarien. Sagen Sie zu Beginn, was Sie vom Review wollen: eine Genehmigung, eine Liste von Risiken oder eine Wahl zwischen zwei Optionen. Präsentieren Sie die Treiber vor dem Design, denn ein Reviewer kann ein Design nicht beurteilen, ohne zu wissen, welche Qualitäten es erreichen muss. Gehen Sie ein oder zwei Szenarien mit der Technik „einer Anfrage folgen“ durch, einschließlich eines Fehlerfalls. Zeigen Sie die Abwägungen, die Sie getroffen haben, und die Risiken, die Sie kennen; ein Reviewer, der ein Risiko findet, das Sie bereits aufgelistet haben, vertraut Ihnen mehr, nicht weniger. Halten Sie jeden angesprochenen Punkt mit einer verantwortlichen Person fest und senden Sie die Liste danach herum.

Regeln für die visuelle Gestaltung von Diagrammen

Diagramme kommunizieren, bevor jemand ein Wort liest, deshalb zählt ihre visuelle Gestaltung. Die folgenden Regeln stammen aus den C4-Notationsempfehlungen in Das C4-Modell und aus allgemeinem Informationsdesign. Das Vorher-nachher-Diagramm wendet sie auf dieselben fünf Elemente an.

Mit Meinungsverschiedenheiten umgehen und Konsens aufbauen

Meinungsverschiedenheiten über Architektur sind normal und gesund: Meist bedeuten sie, dass Menschen unterschiedliche Risiken sehen. Ziel ist nicht zu gewinnen, sondern eine Entscheidung zu erreichen, die diejenigen, die damit leben müssen, verstehen und mittragen. Mehrere Praktiken helfen.

Trennen Sie Interessen von Positionen. Wir müssen Kafka verwenden ist eine Position; Ich mache mir Sorgen, dass wir bei Deployments Ereignisse verlieren ist ein Interesse, und Interessen lassen sich oft auf mehrere Arten erfüllen. Vereinbaren Sie die Kriterien, bevor Sie Optionen vergleichen, wie in einer gewichteten Entscheidungsmatrix; die meisten hitzigen Debatten sind eigentlich Uneinigkeit darüber, was zählt, und sie kühlen ab, sobald das ausgesprochen ist. Klären Sie Unsicherheit mit Belegen: Ein zweitägiger Spike oder ein Lasttest entscheidet viele Debatten, die Meetings nicht entscheiden können. Schreiben Sie es auf: Ein vorgeschlagenes ADR oder Design Doc lässt alle in ihrem eigenen Tempo kommentieren und gibt ruhigeren Kollegen eine Stimme.

Streben Sie Zustimmung statt Einstimmigkeit an. RFC 7282 der IETF (Pete Resnick, 2014) beschreibt Rough Consensus: Eine Entscheidung ist erreicht, wenn jeder Einwand behandelt wurde, also erwogen und beantwortet, wenn auch nicht unbedingt berücksichtigt. Die Frage Kann jemand damit nicht leben, und warum? bringt blockierende Punkte schneller ans Licht als die Frage, ob alle zustimmen. Ist Konsens nicht möglich, muss jemand entscheiden, und es sollte vorab klar sein, wer. Jeff Bezos’ Aktionärsbrief von 2016 machte Disagree and Commit populär: Menschen äußern ihre abweichende Meinung offen und stehen dann voll hinter der Entscheidung, sobald sie gefallen ist. Halten Sie die abweichende Meinung und die Gründe im ADR fest; behalten die Abweichenden recht, zeigt der Record, was zu überdenken ist und warum.

Zwei Fehlmuster verdienen eine Warnung. Die Architektin, die jede Diskussion kraft ihres Dienstalters gewinnt, hört nichts mehr von Problemen. Das Team, das ohne Einstimmigkeit nicht entscheiden kann, lässt wichtige Entscheidungen durch Untätigkeit fallen, das Gegenteil des Last Responsible Moment.