Architektur über den Lebenszyklus: vorab geplante, emergente und kontinuierliche Architektur

Der alte Streit: vorab oder emergent?

Den größten Teil der Softwaregeschichte über war Architektur etwas, das man am Anfang erledigte. In einem sequenziellen Prozess („Wasserfall“) wurden Anforderungen gesammelt, dann wurden eine Architektur und ein Detailentwurf erstellt und freigegeben, und dann wurde das System nach diesem Entwurf gebaut. Das ist Big Design Up Front (BDUF). Seine Logik ist in manchen Umgebungen stichhaltig: Wenn Anforderungen stabil und gut verstanden sind, wenn Änderungen nach der Auslieferung extrem teuer sind (Flugsoftware, Medizinprodukte, hardwaregebundene Systeme) oder wenn viele Auftragnehmer Teile bauen müssen, die zusammenpassen, verringert ein gründlicher Entwurf vor dem Bau das Risiko.

Seine Schwächen sind ebenso bekannt. Anforderungen ändern sich, und ein aufwendiger, früh erstellter Entwurf schreibt Annahmen fest, die sich später als falsch erweisen. Feedback aus der echten Nutzung kommt erst am Ende, wenn Änderungen am teuersten sind. Teams entwerfen für eingebildete Bedürfnisse („wir müssen vielleicht fünf Währungen unterstützen“) und bezahlen für Flexibilität, die niemand nutzt. Und Dokumente, deren Freigabe Monate gedauert hat, werden meist noch befolgt, wenn sie längst nicht mehr stimmen.

Agile Methoden waren eine Reaktion darauf. Vor allem Extreme Programming trat für emergentes Design ein: das Einfachste bauen, das für die anstehenden Features funktioniert, den Code mit kontinuierlichem Refactoring und automatisierten Tests sauber halten und das Design mit dem System wachsen lassen. Kent Becks Regeln für einfaches Design und der Grundsatz „you aren’t gonna need it“ (YAGNI) drücken denselben Gedanken aus. Emergentes Design funktioniert gut innerhalb eines Moduls und bei kleinen Systemen, in denen jede Entscheidung eine Zweiwegtür ist. Seine Schwäche zeigt sich im großen Maßstab: Manche Entscheidungen (das Datenmodell eines System of Record, die Grenzen zwischen Teams, das Sicherheitsmodell, die Wahl zwischen synchroner und asynchroner Integration) sind teuer rückgängig zu machen und prägen alles, was darauf aufbaut. Überlässt man sie der Emergenz, werden sie oft zufällig von dem getroffen, der den ersten Code schreibt.

Was das Agile Manifest sagt und was nicht

Einer der zwölf Grundsätze hinter dem Agilen Manifest (2001) lautet: Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams. Er wird häufig zitiert, als bedeute er, dass agile Teams keine Architektur oder keine Architekten brauchen. Das sagt er nicht.

Genau gelesen trifft der Grundsatz eine Aussage darüber, wer die besten Architekturen hervorbringt (die Menschen, die das System bauen, selbst organisiert statt von außen gesteuert), und wie (sie entstehen durch die Arbeit, statt fertig vorgegeben zu werden). Er sagt nichts darüber, dass Architektur unwichtig sei, und dasselbe Dokument enthält einen weiteren Grundsatz: Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität. Ein Team, das strukturelle Entscheidungen ignoriert, folgt nicht dem Manifest; es ignoriert die Hälfte davon.

Was der Grundsatz tatsächlich ausschließt, ist eine Architektur, die aus dem Elfenbeinturm von Leuten verordnet wird, die nicht mit ihren Folgen leben müssen, und eine Phase, in der die Architektur fertiggestellt und eingefroren wird, bevor jemand Code schreibt. In der Praxis sieht der häufigste Ausgleich so aus, dass Architektur zu einer kontinuierlichen, im Team geteilten Tätigkeit wird, bei der ein Architekt (oder architektonisch denkende Entwickler) als Wegweiser, Moderator und Hüter des Gesamtbilds wirkt statt als Torwächter.

Wie viel Architektur? Das risikogetriebene Modell

Wenn keines der Extreme richtig ist, wie viel Architekturarbeit ist dann genug? George Fairbanks gab eine der klarsten Antworten in Just Enough Software Architecture: A Risk-Driven Approach (2010). Sein risikogetriebenes Modell besagt, dass der Aufwand für Architektur dem Risiko des Scheiterns entsprechen sollte. Es hat drei Schritte, die nach Bedarf wiederholt werden: Risiken erkennen und priorisieren (idealerweise als konkrete Ausfallszenarien, etwa „die Buchungsseite läuft in einen Timeout, wenn sich um 8 Uhr 5000 Patienten anmelden“); Techniken auswählen und anwenden, die diese Risiken verringern (ein Modell, ein Prototyp, ein Lasttest, eine Analyse, ein Entwurfsmuster); und die Risikoverringerung bewerten und aufhören, wenn das verbleibende Risiko akzeptabel ist.

Das Modell ist wirkungsvoll, weil es eine Abbruchregel liefert. Ein einfaches internes Werkzeug auf vertrauter Technologie mit wenigen Nutzern birgt wenige Architekturrisiken, und eine Skizze am Whiteboard kann genügen. Eine Zahlungsplattform, die Millionen von Transaktionen abwickelt und reguliert ist, birgt viele und verdient sorgfältige Modellierung, Prototypen und Reviews. Dasselbe Team kann auf verschiedene Teile eines Systems sehr unterschiedlich viel Architektur verwenden. Fairbanks betont auch, dass Zeit für den Entwurf Zeit ist, die nicht für Bauen oder Testen zur Verfügung steht; zu viel Entwurf ist also echte Kosten und kein sicherer Standard.

Beabsichtigte Architektur und die Architectural Runway

Große Organisationen haben ein Koordinationsproblem, das ein einzelnes Team nicht hat: Dutzende Teams müssen Teile bauen, die zusammenpassen. Das Scaled Agile Framework (SAFe), ein weit verbreitetes und ebenso umstrittenes Framework zur Skalierung agiler Praktiken, beschreibt Architektur als Gleichgewicht zwischen emergentem Design innerhalb der Teams und beabsichtigter Architektur: einer bewussten, teamübergreifenden Planung der Strukturen und Richtlinien, die die Teams gemeinsam nutzen. Das Ergebnis nennt es die Architectural Runway: den vorhandenen Code, die Komponenten und die technische Infrastruktur, die nötig sind, um Features der nahen Zukunft ohne übermäßige Umgestaltung und Verzögerung umzusetzen. Arbeit zur Verlängerung der Runway (etwa die Einführung einer Messaging-Plattform vor den Features, die sie brauchen) wird ausdrücklich neben der Feature-Arbeit geplant, und Features verbrauchen die Runway, indem sie sie nutzen.

Neutral beschrieben erfasst die Runway-Metapher etwas, das für jede Organisation gilt: Wenn die Infrastruktur, die ein Feature braucht, noch nicht existiert, wird dieses Feature langsam sein, und der Aufbau der Infrastruktur braucht Vorlaufzeit. Kritiker von SAFe argumentieren, es könne schwerfällige Planung von oben unter agilem Vokabular wieder einführen; Befürworter halten dagegen, dass im großen Maßstab eine gewisse zentrale Koordination unvermeidlich ist. Sie müssen SAFe nicht übernehmen, um die Idee zu nutzen: „Welche Grundlagen brauchen die Features des nächsten Quartals, und bauen wir sie rechtzeitig?“ ist eine gute Frage für jeden Architekten.

Kontinuierliche Architektur

Murat Erder und Pierre Pureur beschreiben in Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World (2015) und Continuous Architecture in Practice (2021, mit Eoin Woods) Architektur als fortlaufenden Strom von Entscheidungen statt als Phase oder Dokument. Ihre sechs Grundsätze lauten: Produkte architektonisch gestalten, nicht nur Lösungen für Projekte; sich auf Qualitätsmerkmale konzentrieren, nicht auf funktionale Anforderungen; Designentscheidungen aufschieben, bis sie absolut notwendig sind; für Veränderung entwerfen und dabei die Stärke kleiner, lose gekoppelter Teile nutzen; für Bauen, Testen, Deployen und Betreiben entwerfen; und die Organisation der Teams nach dem Design des Systems ausrichten, an dem sie arbeiten.

Zwei dieser Grundsätze greifen frühere Abschnitte dieses Kapitels auf: Entscheidungen aufzuschieben ist der Last Responsible Moment, und Teams nach dem System auszurichten ist eine bewusste Anwendung des Gesetzes von Conway. Der praktische Schwerpunkt liegt darauf, dass die Einheit der Architekturarbeit die Entscheidung ist, die festgehalten wird, wenn sie getroffen wird, und auf Feedbackschleifen (automatisierte Tests, Fitness Functions, Monitoring in der Produktion), die dem Team zeigen, ob die Architektur ihre Qualitätsziele noch erfüllt.

Walking Skeletons und Spikes

Zwei einfache Techniken verbinden Architektur und Auslieferung schon ab der ersten Woche. Ein Walking Skeleton, ein Begriff, der mit Alistair Cockburn verbunden wird, ist eine winzige Implementierung des Systems, die eine kleine Funktion von Ende zu Ende durch alle wichtigen Architekturkomponenten ausführt. Bei einem Terminbuchungssystem für ein Krankenhaus könnte es einen Testnutzer anmelden, ihm die freien Termine einer fest eingetragenen Ambulanz aus dem Patientenverwaltungssystem anzeigen, einen davon buchen lassen und eine SMS senden, über die echte Delivery-Pipeline in eine produktionsnahe Umgebung deployt. Es tut fast nichts Nützliches, beweist aber, dass die Teile zusammenpassen, dass die Pipeline funktioniert und dass sich die Architektur bauen lässt. Jedes spätere Feature setzt Fleisch an ein Skelett, das bereits läuft.

Ein Spike (ein weiterer Begriff aus Extreme Programming) ist ein kurzes, zeitlich begrenztes Experiment, um eine Frage zu beantworten oder ein Risiko zu verringern: Kann die PAS-Schnittstelle 50 Anfragen pro Sekunde verarbeiten? Wie lange braucht der Identity Provider, um ein Token auszustellen? Kann unsere gewählte Bibliothek barrierefreie PDFs erzeugen? Spikes werden meist weggeworfen; ihr Ergebnis ist Wissen, festgehalten in einer Entscheidung. Sie sind der günstigste Weg, eine Entscheidung vor ihrem Last Responsible Moment von Vermutungen auf Belege zu stellen.

Architekturtätigkeiten in einem iterativen Zyklus

In einem iterativen Prozess findet Architekturarbeit nicht einmal statt; sie wiederholt sich in jedem Zyklus, in einer Tiefe, die den anstehenden Risiken des Teams entspricht. Der iSAQB-Lehrplan beschreibt die Kernaufgaben des Architekten auf eine Weise, die sich natürlich auf einen solchen Zyklus abbilden lässt, und Die Rolle des Architekten hat sie eingeführt. Hier sind sie als Schleife:

Anforderungen klären: die Stakeholder und Anliegen finden, die Qualitätsziele und Randbedingungen schärfen und die Risiken erkennen (siehe Stakeholder und Anliegen). Strukturen entwerfen: die bedeutsamen Entscheidungen treffen oder überarbeiten, Stile und Muster wählen und Grenzen und Schnittstellen festlegen. Kommunizieren und abstimmen: die Entscheidungen den Menschen erklären, die das System bauen, betreiben und bezahlen, in Sichten, die zu jeder Zielgruppe passen, und sie festhalten. Umsetzung begleiten: mit den Teams arbeiten, während sie bauen, Fragen beantworten, Code reviewen und das Design anpassen, wenn die Realität sich widersetzt. Bewerten: prüfen, ob das System seine Qualitätsziele erfüllt, durch Reviews, Tests, Messungen in der Produktion und automatisierte Fitness Functions. Weiterentwickeln: auf das reagieren, was die Bewertung ergeben hat, Schulden tilgen und sich an geänderte Anforderungen anpassen, was Sie wieder zum Klären der Anforderungen zurückführt.

Architektur in DevOps und Continuous Delivery

Continuous Delivery, bei der jede Änderung gebaut, getestet und releasefähig gehalten wird, und DevOps, das die Verantwortung für Entwicklung und Betrieb zusammenführt, verändern sowohl die Ziele der Architektur als auch ihre Feedbackschleifen.

Sie verändern die Ziele, weil Deploybarkeit, Testbarkeit und Betreibbarkeit zu vollwertigen Qualitätsmerkmalen werden. Ein System lässt sich nicht mehrmals am Tag releasen, wenn Komponenten gemeinsam in fester Reihenfolge deployt werden müssen, wenn Tests eine vollständige Kopie der Produktion brauchen oder wenn niemand am Monitoring erkennen kann, ob ein Release die Lage verschlechtert hat. Die in Accelerate (Nicole Forsgren, Jez Humble und Gene Kim, 2018) zusammengefasste Forschung ergab, dass eine lose gekoppelte Architektur, die es Teams erlaubt, ihre Teile unabhängig zu testen und zu deployen, zu den stärksten Prädiktoren für die Leistung bei Continuous Delivery gehörte. Architektur wird also nicht nur von guter Auslieferungspraxis unterstützt; sie ist eine ihrer Voraussetzungen.

Sie verändern die Feedbackschleifen, weil das laufende System zum ehrlichsten Architektur-Review wird. Produktionsmetriken, Traces und Incident-Reviews zeigen weit zuverlässiger als Diagramme, wo die Architektur schwach ist. Architekturregeln lassen sich als automatisierte Fitness Functions in der Pipeline durchsetzen (Kapitel 11), Infrastruktur wird als Code definiert und wie Code reviewt (Kapitel 10), und Techniken wie Feature-Flags und Canary Releases machen viele Entscheidungen günstig umkehrbar. Die Rolle des Architekten verschiebt sich entsprechend: weniger Freigabe von Dokumenten, mehr Gestaltung der Plattform, der Pipeline und der Guardrails, mit denen Teams schnell gute Entscheidungen treffen können.