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.
Konfliktpotential zwischen Architekturentwicklung und agilen Methoden
Letztendlich widerspricht dies jedoch dem agile Grundsatz, nicht zu viel im Vorfeld klären und dokumentieren zu wollen – schließlich lassen sich Annahmen oft erst kurz vor oder während der Umsetzung validieren und Anforderungen können sich in der heutigen Zeit schnell ändern. Sehr frühe Versuche Klärung herbei zu führen erweisen sich damit häufig als schlechte Lagerhaltung und Investitionen müssen abgeschrieben werden wodurch sich der ROI verschlechtert. Aus diesem Grund sehen viele Experten ein signifikantes Konfliktpotential zwischen traditioneller Architekturentwicklung und Agilität.
Alternative: Verzicht auf Architekturentwicklung?
Manche Entwicklungsteams verzichten deshalb auf die vorgeschaltete Architekturentwicklung und verstehen es auch nicht Architekturentwicklung in ihren agilen Prozess so zu integrieren, dass eine tragfähige Architektur während des Projekts und am Projektende existiert.
Gründe für die ablehnende Haltung gegenüber reiner „Architekturarbeit“ sind sicherlich die Vorstellungen von einem langsamen und dokumentenzentrischen Prozess, der mit der Erstellung einer Softwarearchitektur verbunden sein kann – und in vielen Unternehmen auch damit verbunden ist:
Fülle bitte das Dokument XYZ mit den 200 UML Diagrammen aus, damit ich einen Architektur-Review machen kann!
Das Thema begleitet uns schon lange, so gehen James Coplien & Kevlin Henney 2008 auf dieses Spannungsverhältnis im Rahmen eines Vortrags (Q Con London) ein.
Agile Modeling & Agile Architecture
Scott W. Ambler beschäftigt sich schon seit vielen Jahren im Rahmen seines Agile Modeling und Agile Data damit, wie die neuen Anforderungen an die Architekturentwicklung im Kontext eines agilen, iterativ-inkrementellen Entwicklungsprozesses adressiert werden können. Interessant dabei ist, dass er aktuell als „Chief Methodologist for Agile and Lean“ bei IBM Rational tätig ist.
Eine Zusammenfassung seiner Interpretation einer (organisatorisch) skalierbaren agilen Architektur befindet sich hier: „Agile Architecture: Strategies for Scaling Agile Development„.
Seine Prinzipien für die agile Modellierung lauten:
- Model with a purpose
- Klären, warum etwas modelliert wird und wer die Nutzer des Modells sind.
- Maximize Stakeholder ROI
- Investiere Deine Mittel (Zeit, Aufmerksamkeit, …) so, dass diese den besten ROI für den Auftraggeber ergeben.
- Travel Light
- Denke daran, dass alles stets aktuell gehalten werden muss – reduziere deshalb Anzahl und Detaillierungsgrad auf das Minimum! Jedes Mal, wenn ein Modell/Artefakt beibehalten wird, so wird zwar aufbereitete Information beibehalten aber auch Agilität reduziert. Wäge dies sorgsam ab!
- Multiple Models
- Nutze verschiedene Modellierungstechniken um ein System zu beschreiben. Manche Sachverhalte verlangen nach mehreren, unterschiedlichen Modellen. Die UML mit „Hirn an“ benutzen und die anderen Prinzipien im Kopf behalten!
- Rapid Feedback
- Direktes Feedback ist essentiell. Nutze kollaborative Modellierungstechniken wie Whiteboard, Sticky-Notes etc, um von Deinen Teamkollegen schnell und direkt Feedback zu erhalten.
- Assume Simplicity
- Strebe die einfachste, gerade noch tragfähige Lösung an. Modelliere nichts, was Heute nicht in der Software benötigt wird.
- Embrace Change
- Anforderungen entwickeln sich, Vorstellungen des Auftraggebers ändern sich. Ziele ändern sich. Eine Architektur muss an neue Gegebenheiten anpassbar sein. Je mehr schon im Detail ausmodelliert wurde, umso höher der Änderungsaufwand. Der ROI für den Auftraggeber sinkt.
- Incremental Change
- Die erste Version wird nicht die „richtige, endgültige“ Version sein. Die aktuelle Version muss jedoch stets „gut genug“ sein. Don’t overinvest!
- Quality Work
- Arbeite so, dass Du auf Deine Arbeit stolz sein kannst.
- Working Software is your Primary Goal
- Das Ziel eines Entwicklungsvorhabens ist es, qualitativ hochwertige lauffähige Software zu erstellen. Ziel ist es NICHT unglaublich detaillierte Dokumente zu erzeugen. Jede Aktivität muss daraufhin bewertet werden, ob sie zum primären Ziel (lauffähige Software) direkt beiträgt.
- Enabling the Next Effort is your Seconary Goal
- Stelle sicher, dass das entwickelte System robust genug ist, um über die Zeit erweitert zu werden. Erzeuge genug Dokumentation, um den Betrieb der Lösung zu ermöglichen. Kurz: Werfe stets auch einen Blick in die Zukunft.
Überlegungen zur Investition in eine solide Architektur
Hat man sich nun darauf geeinigt, wie viel Architektur man dokumentieren möchte stellt sich natürlich die Frage, wie viel man „in Architektur investieren“ möchte. Dieser Frage geht Dean Leffingwell in seinem Artikel „Assuring Architectural Integrity via Backlog Class of Service“ nach und stellt im Zuge dessen das Konzept des „Class of Service“ für eine Auslieferung vor.
Wird eine hohe Softwarequalität generell überschätzt?
Recht kritisch setzt sich Kristian Köhntopp in seinem Artikel „Architektur heißt umbauen“ mit Investitinen in Architektur und elegantem Code auseinander. Seine ernüchternde Erkenntnis:
„Es ist gar nicht notwendig, schönen Code zu bauen. […] Genau genommen ist das Kriterium sogar, ob er den Job gut genug getan bekommt.“
Dem gegenüber steht die Forderung vieler Agilisten, unbedingt in elegante Lösungen, sauberen Code und solide Architekturen zu investieren.
Da fällt mir gerade ein, dass ich dieses Thema schon 2009 in meinem Artikel „Verschwendung in der Softwareentwicklung“ aufgegriffen habe.
Wie man sieht – es wird stets spannend, wenn es um Architektur geht!
Martin Fowler sagt dazu: „Do you wanna be an Architect when you grow up?
My favorite was „architects are good for the three B’s: bulbs, bushes, birds“. The notion is that architects come up with all these pretty drawings … In software, the term architect means many things. (In software any term means many things.) In general, however it conveys a certain gravitas, as in „I’m not just a mere programmer – I’m an architect“. This may translate into „I’m an architect now – I’m too important to do any programming“.“
Vielleicht gibt es vereinzelt ja wirklich gute Architekten? Aber die meisten sind nur Leute, die sich zu wichtig nehmen.