Ihre Architektur ist nicht fertig, wenn Sie ein Konzept erstellt, ein Diagramm gezeichnet oder eine Idee formuliert haben. Architekturentscheidungen beeinflussen große Teile der Umsetzungsarbeit und erst durch die Rückmeldung aus der Umsetzung bzw. die Einhaltung der Architekturprinzipien in allen relevanten Systemteilen wird Architektur lebendig. Davor ist Architektur ein Gedankengerüst, böse formuliert ein Luftschloss. Gute Architekturarbeit versucht, bearbeitete Fragestellungen möglichst schnell mit möglichst objektivem Feedback zu versorgen. Das gelingt durch die saubere Formulierung der Ziele von Architekturarbeit (Die Basis für Architekturarbeit) und die konsequente Prüfung von deren Erreichung. Die Muster dieses Kapitels verschreiben sich dieser Prüfung und zeigen, wie Sie frühe Rückmeldungen fördern können, wie Sie Architektureigenschaften im Code analysieren und prüfen können, wie Sie Architekturziele realistisch im Auge behalten und wie Sie mit gefundenen Problemen umgehen können.

Der Programmcode und das laufende System sind als Testgrundlage sehr beliebt, weil es hier keinen Interpretationsspielraum mehr gibt. Was hier getestet wird, das ist die Wahrheit. Architekturideen und Architekturentscheidungen sind um einiges abstrakter. Sie beeinflussen die Umsetzung auf vielen Ebenen und lassen sich weder auf Programmcode noch auf Anforderungen 1 : 1 abbilden. Entscheidungen beeinflussen in Nebeneffekten meist mehrere Anforderungen und einzelne Anforderungen erfordern ihrerseits oft ein Set von Entscheidungen.

Frühes Zeigen
Wie kann früh und in möglichst direkter Zusammenarbeit mit dem Kunden überprüft werden, ob sich die Softwarearchitektur entsprechend der Ziele und Wünsche entwickelt?
Realitätscheck für Architekturziele
Wie können Probleme bei der Erreichung von Architekturzielen frühzeitig erkannt werden?
Qualitative Eigenschaften testen
Wie können Ziele, die die äußere Qualität des entwickelten Systems betreffen, objektiv geprüft werden und negative Seiteneffekte späterer Entwicklungstätigkeiten sichtbar gemacht werden?
Qualitätsindikatoren nutzen
Wie können Ziele, die die innere Qualität des entwickelten Systems betreffen, objektiv geprüft werden und negative Seiten effekte späterer Entwicklungstätigkeiten aufgedeckt werden?
Code und Architektur verbinden
Wie können Architektur und Code am Auseinanderdriften gehindert werden, so dass (1) keine Verwässerung der Facharchitektur auftritt, (2) Architekturschwächen in puncto Umsetzbarkeit erkannt werden und (3) die Gültigkeit von Architekturprüfungen im Code gewährleistet bleibt?
Kontinierlich integrieren / ausliefern
Wie können Ergebnisse von Metriken, Umsetzungsprüfungen oder Tests verschiedener Arten möglichst schnell zurück zum Entwickler fließen, um (1) direktes Feedback zu ermöglichen und (2) die Qualität des Systems stetig hoch zu halten?
Problemen auf den Grund gehen
Wie können für die Architektur erkannte Probleme oder Risiken analysiert werden, um Verschwendung und Ineffektivität bei deren Beseitigung zu vermeiden?