Software-Architektur im agilen Umfeld

Wann lohnt sich Architekturarbeit?

What do we mean by a software architecture? To me the term architecture conveys a notion of the core elements of the system, the pieces that are difficult to change. A foundation on which the rest must be built.

Architekturarbeit und ein gewisses Mass an Planung lohnt sich für all die Bereiche, in welchen viele Risiken und unbekannte Faktoren zu erwarten sind und welche - wie das Zitat von Martin Fowler illustriert - später schwer zu ändern sind.

Entsprechende Entscheidungen gefährden zentrale Rahmenbedingungen: Budget, Zeitplan oder Produktqualität. Unnötig sind starre Designs oder zu frühe Entscheidungen bei Themen, welche sich später leicht ändern lassen oder nur geringe Risiken aufweisen. Es empfiehlt sich also, Architekturarbeit risikogetrieben zu priorisieren.

Hohe Risiken entstehen typischerweise zum Beispiel bei

• Schwierigen Integrationen
• Dem Einsatz von neuen, unbekannten Technologien
• Sehr hohen qualitativen Anforderungen, zum Beispiel an die Performance oder Verfügbarkeit
• Unklaren Zuständigkeiten oder einem hohen Mass an organisatorischen Abhängigkeiten

Wird Architekturarbeit nicht strukturiert angegangen, besteht das Risiko, dass grundlegende nichtfunktionale Anforderungen nicht erfüllt werden können. Im schlimmsten Fall wird dies erst spät im Vorgehenszyklus bemerkt und ist nicht mehr zu ändern. Zum Beispiel ist vielleicht die Performance ohne grundlegenden Neubau nicht mehr auf ein akzeptables Niveau zu heben. Auch leidet höchstwahrscheinlich die Wartbarkeit, und ohne Architekturdokumentation wird es für neue Teammitglieder schwierig werden sich in die Struktur System einzuarbeiten.

Mit der Architekturvision starten

Das Erstellen einer initialen Architekturvision zusammen mit den Stakeholdern und dem Entwicklungsteam ist eine schlanke Möglichkeit, eine gemeinsame Richtung zu erarbeiten. Dies ohne Entscheidungen unnötig früh zu treffen und so das Lernfenster möglichst lange offen zu halten. Die Architekturvision sollte folgende Eckpunkte enthalten:

• Wichtigste Rahmenbedingungen und Ziele
• Systemkontext und Schnittstellen zum Umfeld
• Wichtigste Qualitätsanforderungen (priorisiert)
• Fachliche und technische Risiken

Mit der Zeit können folgende Punkte ergänzt werden sobald sich diese festigen:

• Architekturprinzipien
• Technologie-Stack
• Grobe Gliederung und Domänenmodell

Iterative Architekturarbeit

Wir empfehlen, Architekturarbeit von der Umsetzung zu trennen und im Produkt-Backlog einzuplanen:

• Feature-spezifische Designaufwände als Akzeptanz-Kriterium auf der User Story
• Grössere Architekturentscheidungen und -Aufwände als eigene Qualitätsstory (z.B. Redundanz)
• Als "Merker" in der Definition-of-Done oder Architekturrichtlinien

Damit finden Architekturarbeit und -Entscheidungen auch in agilen Vorgehensweisen ihren Platz - aber transparent, priorisiert, risikogetrieben und iterativ. Die Architekturvision stellt die Leitplanken und Grundlagen bereit, um konsistente Entscheide treffen zu können. Im Gegensatz zu klassischen Vorgehensweisen, wo die Architektur oft als Designarbeit zu Beginn des Projektes verstanden wurde und damit die sich im Projektverlauf ergebende Lernkurve sowie sich ändernde Anforderungen schwierig zu berücksichtigen waren.

Architektur-Rollen

Wie die Architekturarbeit im Team verteilt wird und damit welche Architektur-Rollen je nachdem nötig und sinnvoll sind, hängt von den vorhandenen Architekturfaktoren ab: Ist das System verteilt und komplex, oder ist eine simple Formular-Applikation? Werden neue Technologien benötigt oder sind komplexe Schnittstellen anzubinden? Gibt es sehr hohe Qualitätsanforderungen in einem Bereich, zum Beispiel Antwortzeiten oder Flexibilität? Denkbar ist je nach diesen Faktoren sowie der im Team vorhandenen Erfahrung eines der folgenden Rollenmodelle:

• Kein benannter Architekt: Architekturarbeit wird im Team selbstverantwortlich verteilt
• Architektur-Agenten: Dies sind typischerweise erfahrene Teammitglieder mit Architektur-Kompetenz, welche bei Architekturarbeit unterstützen respektive eine gewisse Verantwortung übernehmen.
• Architekt als Coach: Das Team regelt die Architekturarbeit selbstverantwortlich, wird dabei von eine/r Architekt/in unterstützt falls nötig.
• Klassische Architektenrolle: Die Verantwortung für die Architektur liegt bei einer oder mehreren Personen, welche die Rolle als Software-Architekt/in wahrnehmen. Idealerweise in enger Zusammenarbeit mit dem Team, um einen kurzen Feedbackloop sicherzustellen.

Architektur-Dokumentation

Oft kommt bei beim Einsatz agiler Methodik die Frage nach der Dokumentation auf. Eine Architekturdokumentation ist aus unserer Sicht immer sinnvoll, wobei die darin zu investierende Arbeit von der Komplexität des Systems abhängt. Das wichtigste Element einer solchen Dokumentation sind

• Architekturvision, wichtigste Eckpunkte
• Kontextsicht, was sind die Schnittstellen
• Qualitätsanforderungen: Welche nichtfunktionalen Aspekte sind wichtig, möglichst mit konkreten Zahlen untermauert?
• Architekturentscheidungen: Warum wurde das System so gebaut - das Wie lässt sich meist aus dem Code herauslesen

Nicht zielführend ist es, detaillierte Umsetzungsaspekte des Systems zu dokumentieren, welche sich aus dem Code ergeben und häufigen Änderungen unterworfen sind. Diese sind typischerweise nicht architekturrelevant.

Dabei ist zu überlegen, wer die Stakeholder sind welche die Dokumentation konsumieren. Einer der wichtigsten Stakeholder ist dabei der/die neue Projektmitarbeiter/in, welche damit schnell einen Überblick über das System und dessen Ziele gewinnen möchte.

Die Form der Dokumentation sollte einfach zugänglich und editierbar sein: Kollaborative Systeme wie Confluence eignen sich beispielsweise gut dazu, wie auch Ansätze bei welchen die Dokumentation direkt beim Sourcecode in der Versionsverwaltung z.B. als Markdown oder Asciidoc geführet wird. Gute Erfahrungen haben wir bei einem unserer Kunden auch mit Structurizr gemacht, ein Tool welches erlaubt die Dokumentation als Code zu beschreiben und daraus Sichten zu erstellen.

Interessiert?

Gerne helfen wir dabei, Architektur in agilen Vorgehensweisen zu verankern und aktiv anzugehen: Unsere Kontaktangaben