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

Gemeinsam entscheiden

Analog modellieren

Stakeholder involvieren

Wiederkehrende Reflexion

Architecture Owner

Architekturcommunities

Architektur-Kata

