E-Book, Deutsch, 312 Seiten
Toth Vorgehensmuster für Softwarearchitektur
4. aktualisierte Auflage 2025
ISBN: 978-3-446-48113-8
Verlag: Hanser, Carl
Format: PDF
Kopierschutz: 1 - PDF Watermark
Kombinierbare Praktiken in Zeiten von Agile und Lean
E-Book, Deutsch, 312 Seiten
ISBN: 978-3-446-48113-8
Verlag: Hanser, Carl
Format: PDF
Kopierschutz: 1 - PDF Watermark
- Stimmen Sie Architekturaufwand auf den eigenen Kontext ab.
- Profitieren Sie von aktuellen Erkenntnissen zu Zusammenarbeit und Vorgehen.
- Verzahnen Sie Architektur wirksam mit Implementierung und Auslieferung von Software
- Stärken Sie die Verantwortung in Entwicklungsteams, ohne auf übergreifende Architekturideen zu verzichten.
- Ihr exklusiver Vorteil: E-Book inside beim Kauf des gedruckten Buches
Egal ob »Agile«, »Lean«, »Cloud« oder »Flow« - moderne Vorhaben in der Softwareentwicklung arbeiten dynamisch, hoch flexibel und ergebnisorientiert. Auch Softwarearchitektur kann zielorientiert und pragmatisch entstehen, durch Entwicklungsteams gemeinsam getrieben sein oder »Just-in-time« festgelegt werden. Einen Konflikt zwischen Dynamik und Architektur gibt es nicht. Alles, was es braucht, sind zeitgemäße Praktiken und das richtige Mindset. Dieses Buch beinhaltet kein weiteres Vorgehensmodell für die Softwareentwicklung. Stattdessen werden leichtgewichtige Bausteine guter Architekturarbeit vorgestellt, die problemorientiert eingesetzt werden können, um das eigene Vorhaben zu verbessern.
Das ermöglicht ein schrittweises Lernen und Adaptieren neuer Praktiken, ohne große Einstiegshürde. In der bewährten Struktur von Mustern wird ein übliches Problem aus dem Alltag von Entwicklungsvorhaben geschildert und mit einer methodischen Lösung versehen. Die Lösungen referenzieren aufeinander, sind kombinierbar und ergeben insgesamt das Bild einer neuen Architekturdisziplin.
AUS DEM INHALT //
- Risikogetriebene Softwarearchitektur
- Die Rolle Architecture Owner
- Architekturarbeit in Backlogs
- Architekturvision
- Walking Skeleton
- Architekturprinzipien
- Der Pfad des geringsten Widerstands
- 2-Speed-Architecture
- Architektur-Radar
- NFR-Tests und Chaos Engineering
- Architektur-Communities
- Architektur-Kata
Stefan Toth ist Gesellschafter und Geschäftsführer der embarc GmbH. Er unterstützt Entwicklungsvorhaben und -organisationen als Softwarearchitekt, agiler Coach und Berater. Die Verzahnung von technischen, methodischen und organisatorischen Themen steht dabei oft im Zentrum seiner Arbeit.
Autoren/Hrsg.
Weitere Infos & Material
| 2 | Zeitgemäße 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).
| 2.1 | Das Manifest agiler Architekturarbeit |
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
| 2.1.1 | Kontinuierliche Verbesserung vor Perfektion |
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:
| 2.1.2 | Zielorientierung vor Standardlösungen |
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...
