Agilität und Software-Architektur sind immer für eine Diskussion gut. Ich kann mich gut an diverse (hitzige) Diskussionen erinnern, in denen von stark traditionell geprägten Architekten gefordert wurde, dass doch bitte die Architektur detailliert im Vorfeld zu erstellen wäre. Zudem müsse man sich zu Projektstart darauf festlegen, welche Referenzumgebungen genutzt werden sollen, welche Technologien relevant sind und wie die nicht-funktionalen Anforderungen im Detail lauten. Das ergebe sich doch automatisch aus dem Scope und überhaupt müssen die typischen Sichten auf die Architektur detailliert geplant und beschrieben werden, bevor mit der Umsetzung begonnen wird. Eine Freigabe des Ganzen vor Eintritt in die Umsetzungsphase ist natürlich auch noch bei den entsprechende Entscheidungsinstanzen einzuholen.
Eine Ansicht, die in einem Phasenmodell ohne echte inkrementelle Elemente nicht ganz unbegründet ist und auch einen gewissen Wert hinsichtlich Identifikation und Bewertbarkeit von Risiken darstellt.
Die Realität: Architekturbeschreibung meist veraltet
Wie sieht die Realität in vielen Fällen aus? Eine Vielzahl an umfangreichen Modellierungsartefakten, eine Architektur die die Änderungen im Projektverlauf nicht abbilden kann. Kurz: Eine anfangs schöne Architekturvorstellung gleitet in einen „Architektursumpf“ ab. Der Ruf nach großen Re-Design Phasen wird laut (neue Dokumente, Modelle, Reviews, Freigaben). Das eigentliche Ziel, lauffähige Software zu liefern gerät schnell in den Hintergrund.