Architekturvision, Walking Skeleton, Der letzte vernünftige Moment – ISAQB Agila Rückblick

Ende Januar hatte ich die Gelegenheit, das ISAQB-Modul Agila zu besuchen — ein dreitägiger Workshop von und mit Stefan Toth, der sich genau einem Thema widmet, das mich schon länger beschäftigt: Wie lässt sich Softwarearchitekturarbeit sinnvoll in agile Projekte einbetten?

Anreise und erste Eindrücke

Der Workshop fand im Hotel Victory in der Therme Erding statt — eine durchaus angenehme Kulisse für drei intensive Tage. Da viele Teilnehmer aus weiter entfernten Ecken Deutschlands angereist sind, waren die meisten schon einen Tag vorher vor Ort. Ich selbst war mehr als überpünktlich, was sich im Nachhinein als Glücksfall herausstellte: So hatte ich noch vor dem offiziellen Start die Gelegenheit, einige der anderen Teilnehmer kennenzulernen.

Und was für eine Runde das war: Automotive, Medizintechnik, Versicherungen, Forschungsinstitute — die Branchen könnten kaum unterschiedlicher sein. Ob und in welcher Form Agilität dort jeweils wirklich gelebt wird, das wurde im Verlauf der nächsten drei Tage mal mehr, mal weniger deutlich. Eines aber war von Anfang an klar: Die gut 30 Vorgehensmuster, die dieser Workshop vermittelt, liefern für jeden das ein oder andere brauchbare Werkzeug — ganz unabhängig davon, wie agil der eigene Arbeitsalltag tatsächlich ist.

Tag 1: Was ist eigentlich Softwarearchitektur — und gibt es einen Konflikt mit Agilität?

Nach Begrüßung und einer kurzen Kennenlernrunde ging es direkt in die Tiefe: Was bedeutet agil? Was versteht man unter Softwarearchitektur? Wozu Softwarearchitekturarbeit, und wie kann man sie gut machen?

Die spannendere Frage, die im Raum stand: Beißt sich Softwarearchitektur mit agiler Entwicklung? Auf den ersten Blick könnte man das meinen — Architektur klingt nach viel Planung, nach Big Upfront Design, nach starren Strukturen. Agile Entwicklung hingegen lebt von Flexibilität, schnellen Iterationen und der Fähigkeit, sich auf wechselnde Anforderungen einzustellen.

Die Antwort von Stefan Toth kam schnell und überzeugend: Es gibt keinen echten Konflikt. Der entscheidende Perspektivwechsel: Architektur ist kein Vorschritt zur Entwicklung, sondern entsteht während der Entwicklung. Sie beginnt weich und unvollständig, festigt sich aber mit der Zeit — parallel zum wachsenden Wissen über das System, die Anforderungen und die technischen Möglichkeiten. Das Stichwort hier ist zielorientierte Architekturarbeit: Ideen entwickeln, die risikoreichsten Themen zuerst angehen, Annahmen früh validieren — oder, genauso wertvoll, früh invalidieren.

Tag 2: Architektur als Gemeinschaftsprojekt — und Entscheidungen, die halten

Nachdem das Grundverständnis stand, ging es weiter mit einer Frage, die in der Praxis oft unterschätzt wird: Wie macht man Architekturarbeit zu etwas, das das gesamte Team versteht — und an dem alle mitwirken können?

Ein zentrales Muster hier ist die Architekturvision: Sie repräsentiert das „Wohin wollen wir?" und beschreibt gleichzeitig die grobe Idee, wie wir dorthin kommen. Nicht als starre Blaupause, sondern als geteiltes Bild, das Orientierung gibt ohne zu fesseln. Eng damit verbunden: Wie verankert man Architekturthemen im agilen Prozess? Sprich — wie schafft man es, dass Architekturarbeit nicht zwischen den Sprints verschwindet, sondern explizit im Backlog seinen Platz findet und auch dort als wertschöpfend wahrgenommen wird?

Weiter ging es mit Mustern, die helfen, Architekturentscheidungen methodisch zu treffen. Drei davon sind mir besonders im Kopf geblieben:

• Walking Skeleton: Ein schlankes, aber durchgehendes Grundgerüst des Systems, das früh zeigt, ob die Architekturidee im Großen funktioniert — bevor man sich in Details verliert.
• Architekturprinzipien: Explizit formulierte Leitlinien, die dem Team helfen, in konkreten Situationen konsistente Entscheidungen zu treffen.
• Der letzte vernünftige Moment: Entscheidungen bewusst so lange offenhalten, wie es verantwortungsvoll möglich ist — um mit maximalem Wissen zu entscheiden und unnötig frühe Festlegungen zu vermeiden.

Und dann war da noch das absolute Highlight des Workshops: Diese Muster wurden nicht nur theoretisch besprochen, sondern direkt in einer praktischen Übung angewendet. Die Aufgabe? Eine modulare Murmelbahn bauen — aus Legosteinen. Klingt nach Spielerei — ist es auch, aber auf die beste Art. Wer das mal selbst gemacht hat, versteht sofort, was "Walking Skeleton" in der Praxis bedeutet und wie schnell Architekturentscheidungen unter Zeitdruck getroffen werden müssen.

Tag 3: Dynamisch zusammenarbeiten — und wissen, wo man steht

Im dritten Tag standen zwei Themen im Mittelpunkt, die in der Praxis oft zu kurz kommen: Wie arbeitet man rund um Architekturthemen wirklich dynamisch zusammen — und wie bekommt man ehrliches Feedback über den Zustand der eigenen Architektur?

Für die Zusammenarbeit wurden u.a. folgende Muster diskutiert:

• Architekturwand: Ein gemeinsamer, sichtbarer Ort für aktuelle Architekturthemen und -entscheidungen.
• Konsensentscheidungen: Wie kommt man gemeinsam zu tragfähigen Entscheidungen, ohne endlose Diskussionen zu führen?
• Pfad des geringsten Widerstands: Architekturvorgaben so gestalten, dass der „natürliche" Weg der Entwickler gleichzeitig der architektonisch sinnvolle ist.
• Architekturcommunities: Strukturen schaffen, in denen Architekturwissen aktiv geteilt und weiterentwickelt wird.

Die letzten Stunden gehörten dann dem Thema Feedback: Muster wie Gesundheitscheck, Realitätscheck, Qualitative Tests oder Statische Prüfung geben konkrete Antworten darauf, wie man den tatsächlichen Zustand einer Architektur realistisch einschätzen kann — und nicht erst dann merkt, dass etwas schiefläuft, wenn es zu spät ist.

Fazit: Klare Empfehlung

Drei Tage, ein rundes Paket. Der Workshop hat eine sehr klare und nachvollziehbare Struktur: Vom grundsätzlichen Verständnis über konkrete Muster bis hin zu praktischen Übungen, in denen das Gelernte sofort angewendet wird. Die Murmelbahn bleibt dabei in besonderer Erinnerung — aber auch alle anderen Einheiten waren gut durchdacht und mit echtem Praxisbezug.

Stefan Toth — zugleich Autor des Buchs Vorgehensmuster für Softwarearchitektur, an dem sich dieser Workshop orientiert — ist ein toller Referent. Er erklärt Herausforderungen und die Muster, die helfen können, diese zu überwinden, verständlich und ohne unnötigen Fachjargon. Und er bringt jede Menge Anekdoten aus seiner Arbeit als Berater für Softwarearchitektur mit, die das Ganze greifbar und unterhaltsam machen.

Wer Softwarearchitektur in agilen Projekten besser verankern möchte — oder einfach mehr Werkzeuge in die Hand nehmen will, um Architekturentscheidungen strukturierter und kommunizierbarer zu machen —, dem kann ich ISAQB Agila wärmstens empfehlen.