Wer ist der Architecture Owner?

Wer 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!

Matthias Mohme

Kontaktieren Sie Matthias Mohme

In den ersten Berufsjahren als Konstrukteur im klassischen Maschinenbau tätig, entdeckte der 1982 geborene Dipl. Ing. aus München in den darauf folgenden Jahren als Produktmanager seine Leidenschaft für SCRUM und KANBAN in der Softwareentwicklung. Seine Erfahrungen und Beobachtungen, wie sich die Einführung Agiler Methoden auf Mitarbeiter, Teams und ganze Organisationen auswirkt, gibt er als Consultant für Anforderungsmanagement bei der HOOD GmbH weiter.