Bewertung, Entscheidungsfindung und Governance

Willkommen zu Kapitel 11, Bewertung, Entscheidungsfindung und Governance. Die vorherigen Kapitel haben Ihnen gezeigt, wie man beschreibt, was ein System leisten muss, wie man es strukturiert und wie man es schnell, zuverlässig, sicher und wirtschaftlich macht. In diesem Kapitel geht es um die Arbeit, die diese Entscheidungen über die gesamte Lebensdauer eines Systems begleitet: sie prüfen, bevor Geld gebunden wird, sie gültig halten, während jeden Monat Hunderte von Änderungen eingehen, und sie wirtschaftlich und ethisch begründen.

Das Kapitel richtet sich an erfahrene Entwickler, technische Leads und Architekten, die wesentliche Entscheidungen treffen oder begleiten. Hier kommt der Kurs zusammen, daher baut es auf allen vorherigen Kapiteln auf. Am häufigsten verweist es auf die Kapitel eins bis vier zurück: Abwägungen, technische Schulden, Qualitätsszenarien, das Gesetz von Conway und Entscheidungsdokumente. Die Kapitel fünf bis zehn helfen, sind aber nicht zwingend nötig. Das Niveau ist fortgeschritten, aber jeder Abschnitt beginnt mit einer kurzen Erklärung für Neulinge. Und es führt zu Kapitel zwölf, das die gesamte Disziplin auf Systeme anwendet, die um Modelle der künstlichen Intelligenz herum gebaut sind.

Das durchgehende Beispiel ist die Essenslieferplattform, die wir seit Kapitel zwei verwenden. Sie sehen, wie ihre Architektur bewertet, per Risk-Storming untersucht, durch Fitness Functions geschützt, gesteuert, um Teams herum neu organisiert und teilweise modernisiert wird. Abschnitt elf Punkt eins behandelt die formale Bewertung mit der Architecture Tradeoff Analysis Method, kurz ATAM: ihre neun Schritte in zwei Sitzungen, wer teilnimmt, und ihre Ergebnisse, etwa Risiken, Sensitivitätspunkte, Trade-off-Punkte und Risikothemen. Abschnitt elf Punkt zwei erklärt, warum monatliche Review-Gremien so oft scheitern und was stattdessen funktioniert: Risk-Storming, das Pre-Mortem, Architektur-Katas und schriftliche Design-Reviews. Abschnitt elf Punkt drei macht aus der einmaligen Bewertung einen dauerhaften Schutz. Eine Fitness Function ist eine objektive Prüfung eines Architekturmerkmals, idealerweise automatisiert, etwa eine Abhängigkeitsregel oder ein Lasttest mit Perzentil-Schwellenwerten. Abschnitt elf Punkt vier fragt, wie eine Organisation mit vielen autonomen Teams ihre Architektur stimmig hält: durch Prinzipien, Standards, Guardrails und Gates, den Advice Process und Technologieradare.

Dieses Diagramm aus Abschnitt elf Punkt vier stellt zwei Arten der Steuerung gegenüber. Bei der Gate-basierten Governance entwirft ein Team und wartet dann wochenlang in der Warteschlange eines Review-Gremiums. Wird der Entwurf abgelehnt, wird er überarbeitet und wartet erneut. Erst nach der Genehmigung kann das Team bauen und ausliefern. Bei der Guardrail-basierten Governance entscheidet das Team, und seine Änderung durchläuft eine Pipeline mit Guardrails: Policy as Code und Fitness Functions, die objektive Regeln automatisch prüfen. So kann sie in Minuten das Release erreichen. Darunter liegen die unterstützenden Elemente: der Advice Process für wesentliche Entscheidungen, Prinzipien und ein Technologieradar für die gemeinsame Richtung und eine Paved Road aus Vorlagen und Plattform. Guardrails halten den Menschen den Rücken frei für die Entscheidungen, die Urteilsvermögen erfordern. Und im Advice Process darf jeder eine Architekturentscheidung treffen, nachdem er die Betroffenen und Fachleute um Rat gefragt hat, und sie dokumentieren.

Abschnitt elf Punkt fünf nimmt das Gesetz von Conway als Entwurfswerkzeug ernst. Er stellt Team Topologies vor: vier Teamtypen, drei Arten der Zusammenarbeit zwischen Teams und die Grenzen der kognitiven Last eines Teams. Abschnitt elf Punkt sechs befasst sich mit den Systemen, die bereits existieren: warum Big-Bang-Neuentwicklungen so oft scheitern und welche schrittweisen Techniken funktionieren. Abschnitt elf Punkt sieben behandelt die menschliche Seite der Rolle: führen ohne formale Autorität, Vertrauen aufbauen, Entscheidungen moderieren, mit Konflikten umgehen und mit der Geschäftsleitung kommunizieren. Und Abschnitt elf Punkt acht schließt das Kapitel mit zwei Argumenten ab, die ein Architekt gut vorbringen muss: dem Business Case mit Kapitalwert und Amortisationszeit und der ethischen Begründung, einschließlich vorhersehbarer Schäden und Nachhaltigkeit.

Dieses Diagramm aus Abschnitt elf Punkt sechs zeigt eine dieser Techniken, den Strangler Fig: ein Altsystem Stück für Stück ersetzen, während es weiterläuft. Zuerst: abfangen. Clients rufen eine Routing-Fassade auf, die noch den gesamten Traffic an den alten Monolithen schickt. Am Verhalten ändert sich noch nichts. Dann die erste Scheibe. Die Fassade schickt ein Feature, die Bestellverfolgung, an einen kleinen neuen Service, mit vorübergehender Datensynchronisation zwischen Alt und Neu. Scheibe für Scheibe wandert der größte Teil des Traffics hinüber, bis nur noch die Abrechnung im alten System übrig ist. Schließlich geht der gesamte Traffic an die neuen Services, und das Altsystem wird abgeschaltet. Die Migration ist erst abgeschlossen, wenn das alte System und der temporäre Code beide entfernt sind.

Architektur ist nicht fertig, wenn das Diagramm gezeichnet ist. Ihre Entscheidungen müssen geprüft, während der Veränderung des Systems geschützt, von den richtigen Personen getroffen, von passend strukturierten Teams getragen und gegenüber Auftraggebern und Gesellschaft begründet werden. Die wirksamsten Architekten machen diese Arbeit leicht und kontinuierlich statt schwer und gelegentlich. Kurze Risiko-Reviews statt jährlicher Audits. Automatisierte Guardrails statt Genehmigungswarteschlangen. Rat statt Erlaubnis. Und schrittweise Migration statt Neuentwicklung. Die Disziplin, die all das zusammenhält, ist die, mit der dieser Kurs begonnen hat: die benötigte Qualität benennen, sie messbar machen, bewusst entscheiden, das Warum aufschreiben und weiter prüfen.

Am Ende des Kapitels können Sie erklären, wann eine Architektur bewertet werden sollte, und entweder eine ATAM oder ein leichtgewichtiges Review wie Risk-Storming durchführen, mit einem Risikoregister und Verantwortlichen. Sie können Fitness Functions entwerfen, die Qualitätsszenarien in automatisierte Prüfungen verwandeln. Sie können eine schrittweise Modernisierung planen, mit Strangler Fig, Branch by Abstraction und Parallelbetrieb. Und Sie können Kapitalwert und Amortisationszeit für einen Business Case berechnen und eine Architektur auf ethische und Nachhaltigkeitsanliegen prüfen.

Sie können das Kapitel der Reihe nach lesen oder direkt zum benötigten Abschnitt springen. Wenn Ihnen ein Gedanke aus einem früheren Kapitel nicht vertraut ist, folgen Sie dem Link dorthin zurück. Planen Sie für das ganze Kapitel etwa dreieinhalb Stunden Lesezeit ein. Am Ende jedes Abschnitts gibt es Fragen zur Selbstkontrolle. Beantworten Sie sie im Kopf, bevor Sie sich die Antworten ansehen. Wenn Sie so weit sind, gibt es einen optionalen Kapiteltest, der etwa fünfundvierzig Minuten dauert. Er umfasst zwanzig Multiple-Choice-Fragen und zwei schriftliche Antworten. Die Bestehensgrenze liegt bei achtzig Prozent.

So ist das Kapitel aufgebaut. Beginnen Sie mit Abschnitt elf Punkt eins, zur Architekturbewertung und zu ATAM. Bis gleich.