Architektur wird von jedem Entwickler mitgestaltet, sobald er eine Zeile Code schreibt, damit einen gewissen Programmierstil verfolgt, Frameworks oder Bibliotheken verwendet, Abhängigkeiten einführt oder Schnittstellen definiert. Ohne Architekturwissen bei Entwicklern und ohne Austausch untereinander muss immer jemand aufräumen, der Wissen und Überblick hat. Diese Aufgabe kann schnell sehr aufwendig werden, alleine weil Entwickler in der Überzahl sind. Die schlimmste Folge ist, dass der architekturwissende, auf das Gesamtbild achtende „Aufräumer“ kaum Zeit für visionäre Arbeit an der Architektur hat. Die Erarbeitung nötiger Konzepte rückt in den Hintergrund, die Vermittlung solcher Konzepte noch viel mehr. Der Ausweg aus dieser Abwärtsspirale? Alle Entwickler müssen etwas Überblick und Kontext haben, wenn sie Entscheidungen treffen, Kompromisse auflösen oder „einfach nur“ implementieren. Ein Schlüssel zu guter Softwarearchitektur ist, dass alle in dieselbe Richtung ziehen.

Letztlich sind aber nicht nur Entwickler von Softwarearchitektur betroffen. Die Auswirkungen von getroffenen und umgesetzten Entscheidungen werden Kunden und Anwender über Jahre begleiten. Sie haben berechtigterweise Mitspracherechte, wenn es um Qualitätsanforderungen geht. Die Muster dieses Kapitels zeigen, wie Sie effektiv mit Stakeholdern zusammenarbeiten können, wie Sie trotz der parallelen Umsetzungsarbeit mehrerer Entwickler oder Teams eine konsistente Architektur gewährleisten, wie Sie Wissensmonopole vermeiden und für Transparenz sorgen.


Informativer Arbeitsplatz


Wie können wichtige Informationen zur Architektur möglichst breit gestreut werden, um (1) Kontext für Entwurf und Entwicklung zu geben und (2) bei schwierigen Entscheidungen und Kompromissen für eine gemein same Basis zu sorgen?

Gemeinsam entscheiden


Wie kann eine Entscheidung effektiv und konkret in einer Gruppe getroffen werden, wenn (1) ein Entscheider (Architekt) delegiert oder (2) die Gruppe selbst für die Entscheidung verantwortlich ist?

Analog modellieren


Wie kann die Zusammenarbeit auf konzeptioneller Ebene unterstützt werden, um Kreativität, Spontanität und eine zielgerichtete, kollektive Problemlösung zu fördern?

Stakeholder involvieren


Wie können Anforderungen und Erwartungen an die Softwarearchitektur effektiv abgeholt und eingeordnet werden, um stetig informierte Architekturarbeit zu leisten?

Wiederkehrende Reflexion


Wie kann nach einer Serie von Entscheidungen mehrerer Entwickler (1) Konsistenz und Integrität sichergestellt werden, (2) das Big Picture im Auge behalten werden und (3) die Kommunikationslast dabei im Rahmen bleiben?

Architecture Owner


Wie kann Architekturarbeit effektiv, koordiniert und gut erledigt werden, wenn Rahmenbedingungen keine völlig selbst organisierten Teams zulassen? Wie können dabei klassische Probleme eines alleinregierenden Architekten vermieden werden?

Architekturcommunities


Wie können Mitarbeiter eines Projekts dabei unterstützt werden, (1) über Architekturthemen nachzudenken, (2) die eigenen Fähigkeiten dahingehend auszubauen und (3) ein gemeinsames Bild zu entwickeln, das konzeptionelle Integrität fördert?

Architektur-Kata


Wie können Architekturfähigkeiten (1) wiederholt geübt und geschärft, (2) auf eine breitere Entwicklergemeinde übertragen und (3) stetig verbessert werden, ohne produktiv zu entwickelnde Systeme in Mitleidenschaft zu ziehen?