Warum Architektur zählt: Änderungskosten, Qualität, Risiko und echte Ausfälle

Die Entscheidungen, deren Fehler teuer sind

Abschnitt 1.1 hat Architektur als die Menge der Strukturen und bedeutenden Entscheidungen definiert, die ein System prägen, wobei sich die Bedeutung an den Änderungskosten bemisst. Dieser Abschnitt stellt die praktische Anschlussfrage: Na und? Warum sollte sich ein Team, ein Product Owner oder eine Finanzdirektorin für Architektur interessieren und nicht einfach nur für Funktionen?

Die kurze Antwort lautet: Die Architektur entscheidet mehr als jeder andere technische Faktor darüber, wie das System beschaffen sein wird: wie schnell, wie zuverlässig, wie sicher, wie günstig im Betrieb und vor allem wie leicht zu ändern. Funktionen sind das, was ein System tut. Die Architektur bestimmt, wie gut es das tut und was es kosten wird, im nächsten Jahr etwas anderes zu tun. Viele große Softwareausfälle und viele teure Erfolge lassen sich auf eine Handvoll struktureller Entscheidungen zurückführen.

Die Architektur bestimmt die Qualitätsmerkmale

Ein Qualitätsmerkmal ist eine messbare Eigenschaft dafür, wie gut ein System seine Aufgabe erfüllt: Performance, Verfügbarkeit, Sicherheit, Änderbarkeit, Skalierbarkeit, Benutzbarkeit, Kosteneffizienz und weitere. Kapitel 2 macht sie präzise. Entscheidend ist hier, dass die meisten Qualitätsmerkmale emergent sind: Sie entstehen daraus, wie die Teile angeordnet sind und zusammenwirken, nicht aus einem einzelnen Stück Code.

Nehmen Sie die Verfügbarkeit. Muss der Checkout eines Onlineshops nacheinander fünf synchrone Aufrufe an Services machen, die jeweils zu 99,9 % der Zeit verfügbar sind, kann die Kette als Ganzes nicht verfügbarer sein als ungefähr 99,5 %, so gut jeder Service auch geschrieben ist, weil sich die Wahrscheinlichkeiten multiplizieren. Eine Queue, damit einige dieser Schritte später stattfinden, oder ein Cache für Ergebnisse, damit manche Aufrufe entfallen, ändert die Rechnung. Keine der beiden Änderungen ist innerhalb einer einzelnen Funktion sichtbar; beide sind architektonisch. Performance, Sicherheit und Kosten verhalten sich genauso. Eine sichere Anmeldeseite macht ein System nicht sicher, wenn ein interner Service ohne Authentifizierung aus dem Internet erreichbar ist.

Die Funktionalität ist dagegen meist weitgehend unabhängig von der Struktur. Sie können dieselben Funktionen einer Banking-App als eine einzige deploybare Einheit oder als fünfzig Services umsetzen; die Nutzer sehen dieselben Schaltflächen. Was sich ändert, ist alles andere: wie schnell eine Korrektur ausgeliefert werden kann, was passiert, wenn ein Teil ausfällt, wie viele Entwicklerinnen und Entwickler das System aufnehmen kann und wie die Cloud-Rechnung aussieht.

Kosten und Tempo von Änderungen

Der Großteil der Kosten eines erfolgreichen Systems entsteht nach dem ersten Release, wenn es an neue Anforderungen angepasst wird. Die Struktur ist deshalb vor allem wichtig, weil sie bestimmt, wie teuer jede künftige Änderung wird. In einem gut strukturierten System betrifft eine Änderung der Steuerregeln ein Modul. In einem verworrenen System betrifft sie zwanzig, die alle getestet und abgestimmt werden müssen.

Martin Fowlers Design Stamina Hypothesis (2007) fasst den Effekt. Ein Team, das wenig auf die innere Struktur achtet, liefert anfangs oft schneller. Mit der Zeit bremst das angesammelte Durcheinander jede Änderung, und ein Team, das in Struktur investiert hat, überholt es. Fowler nennt dies eine Hypothese, weil es schwer streng zu messen ist, und er vermutet, dass der Kreuzungspunkt meist nach Wochen statt Monaten kommt. Die Verlangsamung sind die Zinsen auf die technischen Schulden, die Abschnitt 1.7 behandelt.

Risiko, Teams, Kommunikation und Schätzung

Risiko. In der Architektur werden die meisten technischen Risiken entweder eingedämmt oder verstärkt. Ein Entwurf mit einem Single Point of Failure, einer ungetesteten Integration zwischen unabhängig gebauten Teilen oder einer unerprobten Technologie im Kern trägt ein Risiko, das keine noch so sorgfältige Programmierung beseitigt. Ein Großteil der Architekturarbeit ist Risikomanagement: erkennen, was gründlich schiefgehen könnte, und die Struktur so gestalten, dass es entweder nicht passieren kann oder nur begrenzten Schaden anrichtet, wenn es passiert.

Arbeit auf Teams aufteilen. Melvin Conway beobachtete 1968, dass Organisationen, die Systeme entwerfen, dazu neigen, Entwürfe hervorzubringen, die ihre eigenen Kommunikationsstrukturen abbilden. Das heißt heute Gesetz von Conway, und es wirkt in beide Richtungen. Ein System, dessen Teile klare Grenzen und schmale Schnittstellen haben, erlaubt mehreren Teams, mit wenig Abstimmung parallel zu arbeiten. Ein System, in dem alles von allem abhängt, zwingt jedes Team in jedes Meeting. Architektur und Organisationsgestaltung sind daher eng verflochten, wie der Abschnitt zum Gesetz von Conway in Kapitel 3 erklärt.

Kommunikation. Eine Architektur gibt Menschen ein gemeinsames Vokabular und eine gemeinsame Landkarte. Neue Entwicklerinnen und Entwickler lernen das System schneller, Produktmanager verstehen, warum manche Wünsche billig und andere teuer sind, und der Betrieb weiß während eines Incidents, was wovon abhängt.

Schätzung und Planung. Die Zerlegung in bekannte Teile macht Schätzungen erst möglich: Eine Änderung lässt sich auf die Komponenten zurückführen, die sie berührt, und jede kann von dem Team geschätzt werden, das sie kennt. Ohne klare Struktur sind Schätzungen geraten, weil niemand mit Sicherheit sagen kann, wie weit eine Änderung Kreise zieht.

Fallstudie: Knight Capital, 1. August 2012

Knight Capital war einer der größten Market Maker für US-Aktien. Laut der Verfügung der US-Börsenaufsicht SEC (Securities and Exchange Commission) vom 16. Oktober 2013 sandte Knights automatischer Order-Router (SMARS genannt) in den ersten 45 Minuten des Handels am 1. August 2012 Millionen unbeabsichtigter Orders an den Markt, während er 212 kleine Privatkundenorders verarbeitete. Er erhielt mehr als 4 Millionen Ausführungen in 154 Aktien, über 397 Millionen Stück, und blieb auf großen ungewollten Positionen sitzen. Knight verlor mehr als 460 Millionen USD, brauchte binnen Tagen eine Notfallinvestition von außen, und die SEC verhängte später eine Geldbuße von 12 Millionen USD wegen Verstößen gegen die Marktzugangsregeln.

Die SEC-Verfügung beschreibt den Mechanismus. Jahre zuvor hatte Knight eine alte Funktion namens Power Peg nicht mehr verwendet, doch ihr Code blieb im Router und konnte weiterhin ausgelöst werden: Es war toter Code, der nicht tot war. 2012 schrieb Knight neuen Code für ein neues NYSE-Programm, das Retail Liquidity Program, und dieser neue Code verwendete ein Flag wieder, das früher Power Peg eingeschaltet hatte. Der neue Code wurde manuell auf die acht Server des Routers deployt. Ein Techniker kopierte ihn nicht auf einen davon, kein zweiter Techniker prüfte das Deployment, und Knight hatte kein schriftliches Verfahren, das eine solche Prüfung vorschrieb. Als das Flag eingeschaltet wurde, führten sieben Server den neuen Code aus; der achte deutete das Flag als „Power Peg ausführen“ und sandte Orders, ohne zu erkennen, dass sie bereits ausgeführt waren. Automatische E-Mails, die vor einem Problem warnten, wurden vor Markteröffnung verschickt, aber niemand handelte danach.

Es wäre unfair, dies einfach einen Programmierfehler zu nennen, und ebenso unfair, es als reinen Betriebsfehler abzutun. Die architektonischen Lehren betreffen Struktur und Deploybarkeit: veraltete Funktionalität, die in einem Produktivsystem erreichbar blieb; ein Flag mit zwei Bedeutungen in verschiedenen Codeversionen; ein Deployment-Prozess ohne automatische Prüfung, ob alle Server dieselbe Version ausführten; und, wie die SEC betonte, unzureichende Kontrollen, um den Schaden zu begrenzen, sobald etwas schiefging. Jede davon ist eine Entscheidung darüber, wie das System gebaut und ausgeliefert wird, nicht über eine einzelne Codezeile.

Fallstudie: der Start von HealthCare.gov, Oktober 2013

HealthCare.gov, der bundesweite Marktplatz für Krankenversicherungen in den USA, öffnete am 1. Oktober 2013 für Anmeldungen. Viele Menschen konnten keine Konten anlegen oder Anträge abschließen, und die Website litt wochenlang unter Ausfällen. Der US-Rechnungshof GAO (Government Accountability Office) und das Office of Inspector General (OIG) des Gesundheitsministeriums (Department of Health and Human Services) untersuchten den Fall später; ihre Ergebnisse sind die beste Quelle dafür, was schiefging.

Der GAO-Bericht vom Juli 2014 (GAO-14-694) stellte fest, dass die Centers for Medicare and Medicaid Services (CMS) Aufträge vergaben, bevor zentrale Anforderungen geklärt waren, dass sich die Anforderungen ständig änderten, dass die Aufsicht schwach war und dass CMS das System startete, ohne zu prüfen, ob es seine Performance-Anforderungen erfüllte. Die Verpflichtungen aus dem Hauptvertrag für den Marktplatz stiegen zwischen 2011 und Anfang 2014 von 56 Millionen USD auf mehr als 209 Millionen USD. Ein zweiter GAO-Bericht vom März 2015 (GAO-15-238) stellte fest, dass die Systeme vor dem Start nicht vollständig getestet worden waren und dass zu den Problemen beim Start eine unzureichende Kapazitätsplanung, Programmierfehler und geplante, aber nicht umgesetzte Funktionen gehörten. Die Fallstudie des OIG von 2016 nannte das Fehlen einer klaren Leitung und die schlechte Abstimmung zwischen fachpolitischer und technischer Arbeit als zentrale Ursachen. Nach intensiven Korrekturarbeiten konnte die Website innerhalb von etwa zwei Monaten eine hohe Nachfrage bewältigen.

Die Geschichte von HealthCare.gov handelt vor allem vom Programmmanagement, doch ihre architektonische Lehre ist direkt. Der Marktplatz wurde von mehreren Auftragnehmern als getrennte Teile gebaut, die zusammenarbeiten mussten, darunter ein Daten-Hub mit Anbindung an andere Bundesbehörden, und niemand prüfte durchgängig unter realistischer Last, ob das zusammengesetzte Ganze seine Kapazitäts- und Performance-Ziele erreichte. Qualitätsmerkmale wie Kapazität sind Eigenschaften des Gesamtsystems; sie lassen sich daher nur von jemandem sicherstellen, der die Struktur des Gesamtsystems verantwortet und es als Ganzes testet.

Fallstudie: Prime Video und Architektur als Passung, nicht als Mode

Im März 2023 veröffentlichte ein Engineer aus dem Video-Quality-Analysis-Team von Amazon Prime Video im Prime Video Tech Blog einen Beitrag über einen Service, der Videostreams auf Qualitätsmängel überwacht. Die erste Version war aus verteilten Serverless-Komponenten gebaut: AWS Step Functions orchestrierte die Schritte, und AWS-Lambda-Funktionen erledigten die Arbeit, wobei Zwischenbilder des Videos über den Speicher Amazon S3 zwischen den Schritten weitergereicht wurden. Das Team berichtete, dass dieser Entwurf bei etwa 5 % der erwarteten Last an eine harte Skalierungsgrenze stieß und bei voller Last zu teuer gewesen wäre, vor allem wegen der Orchestrierungsgebühren pro Schritt und der vielen Speicheranfragen.

Das Team verlagerte die Medienkonvertierung und die Fehlererkennung in einen einzigen Prozess, der in Containern auf Amazon ECS lief, reichte die Bilder im Arbeitsspeicher statt über den Speicher weiter und skalierte, indem es mehr Kopien dieses Prozesses startete. Laut dem Beitrag sanken die Infrastrukturkosten um über 90 %, und der Service konnte weiter skalieren. Der Beitrag wurde vielfach als „Amazon gibt Microservices auf“ geteilt, was er nicht sagte: Die Änderung betraf einen Service, und der Autor merkte an, dass Microservices und Serverless-Komponenten bei hoher Last durchaus funktionieren, die Wahl zwischen ihnen und einem Monolithen aber von Fall zu Fall getroffen werden muss.

Die Lehre ist nicht, dass Monolithen Serverless schlagen. Sie lautet, dass es bei Architektur um Passung geht. Der Serverless-Entwurf war schnell gebaut und für eine frühe, kleinere Arbeitslast angemessen. Als das prägende Merkmal der Arbeitslast (sehr große Datenmengen, die für jede Sekunde jedes Streams zwischen den Schritten weitergereicht werden) dominierte, war eine Struktur, die diese Daten viele Male über das Netzwerk bewegte, die falsche Wahl, und eine andere Struktur passte besser. Ein guter Architekt fragt, was die Arbeitslast, das Team und das Budget brauchen, nicht, was gerade in Mode ist.