Vorgehensmuster für Softwarearchitektur

Auf den nächsten Seiten tauchen Sie in die inhaltliche Vision des Buchs ein. Die übergreifende Idee hinter den 28 Vorgehensmustern für Softwarearchitektur ist in Abschnitt 2.1 detailliert dargestellt und mit den Konzepten der übrigen Kapitel verbunden. Nach diesem vielleicht wichtigsten Abschnitt des gesamten Buchs zeige ich, was diese Idee für das Architektur-Rollenmodell bedeutet. Immer wieder treten Fragen auf, wie die Architekturrolle in agilen Kontexten ausgestaltet werden kann. In Abschnitt 2.2 gebe ich vier mögliche Antworten. Abschnitt 2.3 liefert einen kompakten Überblick der Kapitel zu Vorgehensmustern, bevor ich kurz auf das Fallbeispiel eingehe, das Sie durch alle Vorgehensmuster begleiten wird (Abschnitt 2.4).

Hinter den Vorgehensmustern dieses Buchs steht eine konsistente Vision zeitgemäßer Softwarearchitekturarbeit. Bereits die in Abschnitt 1.3 genannten Definitionen von Softwarearchitektur scheren nicht alle Softwareentwicklungsvorhaben über einen Kamm. Menge und Ausprägung von grundlegenden, risikoreichen Fragestellungen sind von System zu System unterschiedlich. Zeitgemäße Softwarearchitektur erkennt diese Individualität auf vielen Ebenen an:

       Wir nutzen (automatisierte) Feedback-Mechanismen, um ausgehend von einer ersten Design-Idee Systeme stetig zu verbessern und weiterzuentwickeln - Kontinuierliche Verbesserung vor Perfektion (Abschnitt 2.1.1).

       Wir brechen die Zielsetzung von Softwaresystemen so weit herunter, dass wir die individuell passendsten technischen Lösungen finden können - Zielorientierung vor Standardlösungen (Abschnitt 2.1.2).

       Wir fördern rollenübergreifende Kollaboration, um die Komplexität heutiger Software- und Architekturentwicklung bewältigen zu können - Kollaboration vor Isolierter Spezialisierung (Abschnitt 2.1.3).

       Wir etablieren breite Verantwortungsstrukturen und weiche Architekturstandards, um auch bei Problemen reaktionsfähig und dynamisch zu bleiben - Breite Verantwortung vor Zentralisierung (Abschnitt 2.1.4).

Ich greife diese Punkte im Folgenden auf, beschreibe sie etwas detaillierter und referenziere auf wichtige Vorgehensmuster. Davor sei mir der Spaß erlaubt, sie in einem "Manifest agiler Architekturarbeit" festzuhalten .

Bild 2.1 Das Manifest der agilen Architekturarbeit

In der Architekturarbeit streben wir nach besonders gut aufgestellten Systemen. Softwarelösungen sollen gut wartbar sein, sich über die Zeit verändernden Rahmenbedingungen stellen können, stabil sein und unterschiedlichen Performanz-, Last- und Sicherheitsvorstellungen entsprechen. Auf Lösungsseite sehen wir uns für die Erreichung dieser Ziele mit einer Vielzahl von Optionen konfrontiert. Neben Laufzeitumgebungen und Plattformen können wir über Sprachen, Technologien, Frameworks, Protokolle, Bibliotheken, die Strukturierung der Lösung, Schnittstellendesign und andere Themen nachdenken. Es entsteht eine komplex verwobene Designaufgabe, die noch dazu nicht statisch ist. Sowohl Zielsetzungen als auch Lösungsoptionen entwickeln sich ständig weiter. Wie gut kann in diesem Kontext ein Systementwurf eigentlich sein? Und wie lange ist er haltbar?

Bild 2.2 zeigt den Microservices Graph von Uber. Ohne in Details einzusteigen, wird schnell klar, dass wir es mit einem auf Makroebene unübersichtlichen Softwaresystem zu tun haben. Es ist hier schlicht nicht möglich, die Auswirkung jeder Veränderung a priori zu kennen. Analysen von funktionalen Anpassungen oder architektonisch neuen Ideen sind teuer und ineffektiv. Statt langer Planungsphasen und teurer Analyse arbeitet Uber deshalb (wie andere Internetfirmen mit komplexen Lösungen auch) mit kleinteiligen Änderungen und umfassenden Qualitätsprüfungen. Iteration ist also wichtiger als Planung.

Bild 2.2 Der Uber Microservice Graph1)

Bei Microservices ist die Komplexität oft sehr plastisch sichtbar. Ich habe jedoch schon viel kleinere, nicht der Microservices-Architektur folgende Systeme gesehen, die ähnliche Abhängigkeitsnetze zwischen Entitäten oder Komponenten aufspannen. Und: Die Komplexitätsfaktoren aus der Einleitung gelten immer. Architektur ist deshalb keine exakte Wissenschaft.

Frederick Brooks begibt sich in seinem Buch "The Design of Design" [Bro10] auf die Suche nach perfekten Lösungen. In einer Fingerübung mit einem Kollegen versuchte er, einen Entscheidungsgraph für das Softwaredesign eines einfachen Radioweckers zu zeichnen. Pfeile sollten die Abhängigkeiten zwischen den Entscheidungspunkten zeigen und der fertige Graph macht nicht nur unterschiedliche Designwege, sondern auch die letztendlichen Lösungsoptionen sichtbar. Die ursprüngliche Idee war, die unterschiedlichen Lösungsoptionen zu bewerten, um dann den Weg zur besten Option zurückzuverfolgen. Die optimalen Entscheidungen liegen auf dem Pfad zur besten Lösung und man hätte - für den sehr einfachen Radiowecker - ein perfektes System gefunden. Frederick Brooks ist mit diesem Experiment gescheitert. Er konnte die schiere Menge an Abhängigkeiten zwischen Entscheidungen nicht mehr nachhalten und die Anzahl an Lösungsoptionen explodierte regelrecht.

Was Fred Brooks in einem kleinen System zeigt, ist in moderner Softwareentwicklung Normalität. Wir arbeiten weder mit Vollinformation, noch können wir in dem beschränkt sichtbaren Zeithorizont "optimale" Entscheidungen treffen.

Wir versuchen mit dem Wissen und den Erfahrungen, die wir haben, halbwegs taugliche Architekturideen zu finden. Ob diese Ideen zueinander und zu den Zielsetzungen passen, ist erst durch Iteration und Feedback zu beantworten.

Aus diesen Beobachtungen ergeben sich einige Prinzipien für Architekturarbeit. Wir sollten eine Designidee immer nur als Hypothese betrachten, diese Hypothese schnell mit realistischem Feedback prüfen und Veränderung generell in kleinen Schritten denken (um das Feedback einfacher verarbeiten zu können). Dafür muss die Architekturdisziplin eng mit der Umsetzung (und Auslieferung) verzahnt sein. Bild 2.2 zeigt, wie Architekturarbeit in iterativen Zyklen gemacht wird und durch die Umsetzung validiert bzw. invalidiert wird. Je kleinteiliger und öfter Sie durch den Architekturzyklus laufen können und je schneller Sie die Rückmeldung der Umsetzung wieder auf Architekturseite verarbeiten können, desto agiler und besser wird Ihr Vorhaben aufgestellt sein. In guten Umfeldern dauern Schleifendurchläufe nur Stunden, nicht Monate.

Bild 2.3 Iterative Architekturarbeit mit Umsetzung verzahnt

Wie dieses Buch hilft

Die schlanke Vorabplanung von Architektur und die Techniken zum Umgang mit den besprochenen Unsicherheiten sind Gegenstand von Kapitel 4 - "Methodische Architekturentscheidungen". Passende Rückmeldungen aus der Umsetzung, die möglichst häufig Architekturideen prüfen, sind das Thema von Kapitel 6 - "Realistisches Architektur-Feedback". Dort beschreibe ich den Kern der Verzahnung von Implementierung und Architektur.

Die wichtigsten Muster für diesen Teil der Vision:

       Abschnitt 3.6 Der Innovationsmodus

       Abschnitt 4.3 Architekturvision

       Abschnitt 4.4 Das Walking Skeleton

       Abschnitt 6.3 Qualitative Tests

       Abschnitt 6.6 Kontinuierliches Architektur-Feedback

Es gibt viele Architektur-Blueprints und Empfehlungen zum Bau von Softwaresystemen. Vielleicht gibt es in Ihrer Organisation technologische Lösungen und Frameworks, die "gesetzt" sind, vielleicht nehmen Sie in Ihrem fachlichen Umfeld eine Neigung zu einem bestimmten Architekturstil wahr. Auf Konferenzen und in Artikeln können Sie Abgesänge auf ältere Technologien finden und den neuen Weg aufschnappen, "wie man heute Systeme baut". Insgesamt sind wir in der Architekturarbeit ständig mit Lösungen in Kontakt, die Betrachtung der...