Architektur und Agilität

Will man einmal richtig Spaß haben, so werfe man in eine Gruppe von “Agilisten” und “Traditionalisten” das Stichwort “Architektur”: Als hätte man ein Zündholz in einen Strohhaufen geworfen entflammt sofort eine äußerst emotionale Diskussion, deren Randbereiche zwei Statements markieren: “Ohne eine saubere Anfangsanalyse und solide Anfangsarchitektur kommt kein ernsthaftes Projekt aus” und “Wir brauchen keinen Architekten, die Architektur entsteht beim Programmieren”. Zwischen diesen beiden Extremen findet man fast jede denkbare Zwischenposition.

Ich habe viele dieser Diskussionen verfolgt und bin mittlerweile zu dem Schluss gelangt, dass hier mindestens drei verschiedene Themen munter durchmischt werden:

• Wann wird die Architektur erstellt? Ist die Architektur eine eigene Phase zu Projektbeginn, wird sie zu Beginn jeder Iteration erstellt, oder entsteht Sie während des Programmierens durch Refaktorisieren?
• Wie wird die Architektur repräsentiert? Existiert ein eigenes Dokument oder repräsentiert der Code die Architektur — wobei dann oft Werkzeuge eingesetzt werden, um grafische Darstellungen aus dem Code zu extrahieren und wichtige Eigenschaften zu prüfen, zum Beispiel automatisierte Test, um Abhängigkeiten zu prüfen.
• Wer ist für die Architektur verantwortlich? Gibt einen oder mehrere Architekten? Als Entscheider oder als Moderatoren? Oder ist das Entwicklungsteam gemeinsam verantwortlich?

Ich denke, auf welche “Seite” man sich bei diesen drei Fragen schlägt, hängt entscheidend von der Frage ab, was man sich von der Architektur erwartet. Die Antwort darauf wird oft stillschweigend als “selbstverständlich” vorausgesetzt, ohne zu sehen, dass dort der eigentliche Konflikt liegt:

In traditioneller Sicht soll die Architektur Änderungen an bestehendem Code vermeiden. Sie sollte also so flexibel sein, dass zukünftige oder absehbare Anforderungen möglichst schon abgedeckt sind und ohne Änderungen an bestehendem Code oder zumindest der Architektur implementiert werden können. Architektur versucht die zukünftige Entwicklung vorauszusehen.

In agiler Interpretation soll Architektur Änderungen des Codes und ihrer selbst ermöglichen. Eine gute Architektur kann schnell an neue funktionale und nicht-funktionale Anforderungen angepasst werden. Sie ermöglicht möglichst viele zukünftige Entwicklungen. Änderbarkeit ist daher das Leitmotiv agiler Praktiken wie einfaches Design, testgetriebene Entwicklung, Refaktorisieren und Redundanzvermeidung.

Steht man auf dem Standpunkt, Änderungen an der Architektur seien schlecht und zu vermeiden, so wird man fast zwangsläufig zu dem Ergebnis kommen, dass die Architektur vor der Realisierung von einem starken Architekten erstellt werden müsse und daher nicht im Code repräsentiert werden kann.

Sieht man Änderungen als willkommenes Designwerkzeug, kann man die drei Fragen deutlich entspannter angehen. Die Antworten können sich nach anderen Faktoren richten, wie Kritikalität, Team- und Führungskultur und Erfahrung in der Domäne. Fast alle Kombinationen sind hier möglich; viele von ihnen auch in bestimmten Situationen sinnvoll.

In meinen Projekten kamen einige Teams ohne Architekten aus, andere ernannten irgendwann ein Mitglied zum Hüter der Architektur. Immer waren durch Refaktorisieren entstehende Architekturen in fast allen Qualitätsmerkmalen den zu Beginn erstellten Architekturen deutlich überlegen — und dazu auch noch wesentlich billiger. Zudem halte ich mir gerne Optionen offen.

Dieser Eintrag wurde am 1.5.2008 um 12:56 verfasst und befindet sich in it-agile-blog-planet, Software Design, Refactoring, Agilität. Sie können alle Antworten zu diesem Eintrag über den Feed RSS 2.0 mitverfolgen. Hinterlassen Sie eine Antwort oder einen Trackback-Link zu Ihrer eigenen Homepage.

| Drucken