SuperheroWer vertritt die Architektur gegenüber dem Product Owner, der sich primär für den  Business Value interessiert?
Wer ist dieser „Superheld“, der die Verantwortung trägt – ein “Architecture Owner”?

 

Häufig trifft man auf die Meinung, dass diese Aufgabe einem Architekten zugewiesen werden muss. Das Agile Manifest nimmt zum Thema Architektur und Design wie folgt Stellung:

  • Das neunte Prinzip: Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
  • Das elfte Prinzip: Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.

Die Entwicklung einer Architektur ist also grundsätzlich Aufgabe des Teams.
Damit sind keine Elfenbeinturm-Architektur-Teams gemeint, die die Architektur “machen”. Letztlich existieren Architektur und Design nur im getesteten Code und der Code ist die Architektur. Um auf Änderungen schnell reagieren zu können, ist eine hohe Qualität des Codes nötig.

Um zur Architektur im agilen Sinne zu kommen, ist der steinige Weg zur Shared Code Ownership notwendig. Kein Architekt oder Team ist mehr nur für eine bestimmte Komponente verantwortlich. Shared Code Ownership bedingt auch Shared Design.

„Lead architects“ sind hier aufgrund ihrer Fähigkeiten, Erfahrungen und ihres Wissens wichtig. Sie sind aber nicht verantwortlich dafür, die Architektur zu entwerfen und an die Teams zu übergeben. Sie sind dafür verantwortlich, eine teamübergreifende Kommunikation und Zusammenarbeit zum Thema sicherzustellen und auch die Architekturvision zu vermitteln.

Gute Architekten verlieren nie den Kontakt zum Code. Dazu müssen sie kontinuierlich in den Code schauen und die anderen Entwickler durch Pair Programming und Design-Workshops besser machen. Patterns, Test Driven Development und Continuous Refactoring sind weitere Techniken, die für gute Architekturen sorgen und von einem erfahrenen Architekten in den Teams verankert werden sollen.

Fazit: Die Teams sind die Architecture Owner!