Video zum Artikel

Podcast zum Artikel

Hinweis: Dieses Video und dieser Podcast wurden mithilfe von KI erstellt auf Grundlage der ursprünglichen Inhalten sowie den technischen Erkenntnissen des Autors des Blogartikels.

Was Entwicklungsteams von Film und Theater lernen können

Collaborative Storyboarding ist kreativ, erstaunlich bodenständig und bringt Architektur dorthin, wo sie hingehört: ins Team. Mit ein paar Skizzen, Klebezetteln und einer moderierten Diskussion wird sichtbar, wo die Beteiligten unterschiedliche Vorstellungen haben und welche Lösungswege sich anbieten. Dafür braucht es kein großes Regelwerk. Entscheidend ist, dass alle ihr Wissen einbringen und gemeinsam an der Architektur arbeiten. 

Regisseur:innen, Bühnenbildner:innen, Kameraleute, Lichttechniker:innen und Schauspieler:innen müssen lange vor der eigentlichen Produktion verstehen, welche Wirkung eine Szene haben soll. Dafür nutzt die Film- und Theaterwelt seit den 1930er-Jahren Storyboards. Das sind skizzenhafte Darstellungen, die zeigen, was passieren soll, aus welcher Perspektive, mit welcher Dramaturgie und mit welchen sichtbaren Elementen.

Der große Vorteil von Storyboards ist, dass sie einen gemeinsamen Planungsraum schaffen. Sie sind konkret genug, dass darüber gesprochen werden kann, und leichtgewichtig genug, dass sie wieder geändert werden können. Missverständnisse, Lücken und bessere Ideen fallen auf, solange sie noch mit Stift, Klebezettel oder digitalem Marker korrigiert werden können. Genau dieser Gedanke macht Storyboarding auch für die Softwarearchitektur interessant.

Storyboarding in der Softwareentwicklung

Die Vorteile des Storyboardings lassen sich auch in der Softwareentwicklung nutzen. An die Stelle einer Film- oder Theaterproduktion treten Softwaresysteme, und unsere Szenen sind Umsetzungsvorhaben auf der Ebene von Features, Modulen oder Qualitätszielen. Das Prinzip bleibt gleich: In einer frühen Phase wird die zentrale Idee mit Hilfe von Visualisierungen mit den maßgeblich Beteiligten besprochen und ausgearbeitet. Konzeptionelle Anpassungen sind kostengünstig, da sie sich zunächst auf skizzenhafte Darstellungen beschränken.

Als Praktik liegt Storyboarding nah an der Art und Weise, wie Architekturen in vielen Teams ohnehin entstehen: Formelle und informelle Darstellungen werden um Markierungen, Boxen, Linien und Annotationen ergänzt. Storyboarding verläuft sehr intuitiv und kommt ohne ein schweres Regelwerk aus. Entscheidend ist die Diskussion derjenigen Wissensträger:innen, die für die spätere Umsetzung relevant sind.

Die Szene, die es zu bebildern gilt, ist die jeweilige Architektur. Sie wird durch eine vorab bereitgestellte Auswahl relevanter Sichten sichtbar gemacht (Kasten „Sichten“). Diese werden mit Markierungen und Anmerkungen versehen, idealerweise auf leicht veränderbarem Material wie Whiteboards, Sticky Notes und Klebepunkten. Die Teilnehmenden machen so ihre Annahmen sichtbar und damit für alle greifbar. Sind diese Annahmen erst einmal visualisiert, lassen sich Lösungsansätze besprechen, Fehlannahmen erkennen und Alternativen entwickeln.

Sichten

Sichten sind Beschreibungen themenbezogener Ausschnitte einer Architektur in Form informeller oder standardisierter Diagramme. Sie unterstützen vor allem die Entwurfsarbeit und dienen außerdem der nachträglichen Dokumentation.

Nichttriviale Softwaresysteme sind zu komplex, um sie mit einer einzigen Perspektive ausreichend zu beschreiben. Erst die passende Kombination mehrerer Sichten ergibt ein aussagekräftiges Bild des Systems.

Typische Sichten:

• Die Kontextsicht zeigt das System als Blackbox und macht deutlich, welche Akteure und Nachbarsysteme damit interagieren.
• Die Bausteinsicht beschreibt die statischen Strukturen des Systems.
• Die Laufzeitsicht verdeutlicht zentrale Abläufe.
• Die Verteilungssicht zeigt, wie Bausteine in der Infrastruktur abgebildet werden.

Beim Storyboarding wird auf diese und weitere Sichten zurückgegriffen. Sie stammen entweder aus der vorhandenen Architekturdokumentation oder werden gezielt für die Session vorbereitet. Im Idealfall verbessert die Arbeit mit den Sichten zugleich die Dokumentation selbst.

Konkurrierende Ansätze und widersprüchliche Einschätzungen gehören ausdrücklich dazu. Sie liefern wertvolle Perspektiven, da sie die Annahmen hinter den jeweiligen Vorschlägen offenlegen. Häufig erkennt zunächst nur eine Person eine Chance oder ein Risiko. Die gemeinsame Diskussion macht diese Beobachtung für alle zugänglich und es wird möglich, Annahmen zu prüfen oder zu verwerfen. Damit die Gruppe dabei nicht in endlose Detaildebatten abgleitet, ist eine gute Moderation durch die Facilitator-Rolle (Kasten: „Facilitator“) wesentlich. Das Ergebnis ist ein besseres gemeinsames Verständnis der Architektur und der aktuellen Problemstellung.

Facilitator

„Facilitator“ bezeichnet eine Rolle in kollaborativen Sessions und Workshops. Der Begriff leitet sich vom französischen Verb „faciliter“ ab, was so viel wie „leichter machen“ bedeutet. Damit ist eine Person gemeint, die anderen das Arbeiten erleichtert.

Facilitators leiten die Session und bringen genau das Maß an Methodenwissen ein, das die Gruppe benötigt. So können sich die Teilnehmenden auf das Ziel der Session konzentrieren, ohne selbst erst Methodenexpertise aufbauen zu müssen. Facilitators moderieren Interaktionen und Diskussionen und halten die Session im Fluss. Zur Rolle gehören auch die Vor- und Nachbereitung sowie die Auswahl passender Methoden. Im Architekturkontext erfordert gute Facilitation zudem Erfahrung mit Softwarearchitektur.

Abbildung 1 zeigt ein exemplarisches Szenario auf einem digitalen Whiteboard. Neben vier vorausgewählten Sichten liegt dort eine farbcodierte Liste mit Änderungsszenarien. Die Teilnehmenden haben in einer kurzen Gruppendiskussion markiert, welche Bausteine von den jeweiligen Änderungen betroffen sind. Zwei Szenarien (grün und gelb) berühren mehrere Bausteine, während das rote Szenario zunächst auf einen Baustein begrenzt wirkt. Unklarheiten und Annahmen werden direkt als Sticky Notes festgehalten. Am Ende der Session hat die Gruppe eine gemeinsame Lösungsidee entwickelt und ein besseres Verständnis der Architektur sowie der konkret besprochenen Szenarien erlangt.

Abb. 1: Storyboarding auf einem digitalen Whiteboard

Ein neues Feature gemeinsam durchdenken

Ein individuell entwickeltes Fachsystem soll um eine wichtige Funktion erweitert werden. Das Entwicklungsteam trifft sich für eine Stunde, um mögliche Umsetzungen zu besprechen. Die für die Architektur verantwortliche Person hat den Raum entsprechend vorbereitet: An der Wand hängen eine vereinfachte Übersicht der Systemarchitektur („Big Picture“), eine grobe Modulstruktur („Bausteinsicht“) und eine Darstellung des physischen Deployments („Verteilungssicht“). In diesem Beispiel wurden die Darstellungen auf einem großformatigen Whiteboard skizziert. Als Alternative eignen sich Ausdrucke mindestens im Format DIN A3. Dafür braucht es einen geeigneten Drucker und zumindest eine rudimentäre Architekturdokumentation, aus der sich die Sichten entnehmen lassen. Ein geeigneter Drucker dürfte in den meisten Organisationen verfügbar sein. Eine brauchbare Architekturdokumentation fehlt dagegen überraschend häufig.

Storyboarding hat bewusst einen informellen Charakter. Alles, was die Teilnehmenden davon abhalten könnte, ihre Perspektive zu teilen, Ideen zu äußern oder Fragen zu stellen, wird vermieden. Auch die Moderation bleibt einfach und kann von einem Teammitglied übernommen werden. Diese Person agiert als Facilitator. Ihre Aufgabe besteht im Wesentlichen darin, Flow zu erzeugen: Sie unterstützt die Teilnehmenden dabei, ihre Ideen einzubringen, und hält die Session genau so lange in Bewegung, wie es für ein brauchbares Ergebnis nötig ist. Im Beispiel übernimmt die projektverantwortliche Person diese Rolle. Sie erläutert kurz den Kontext, den Nutzen des neuen Features und die Erwartungen daran.

Anschließend bespricht das Team, welche Änderungen nötig sind und wo sie in den Darstellungen voraussichtlich verortet werden. Eine einfache Technik besteht darin, alle Teilnehmenden gleichzeitig Klebezettel an jene Bausteine anbringen zu lassen, die aus ihrer Sicht angepasst werden müssen. Farbcodierungen helfen dabei, die vermutete Komplexität einer Änderung zu klassifizieren: Grün, Gelb und Pink können beispielsweise für gering, mittel und hoch stehen. Optional können die Klebezettel beschriftet werden, um die Änderung stichpunktartig zu beschreiben.

Bereits bei dieser einfachen Aktivität werden unterschiedliche Annahmen sichtbar. So signalisiert ein Entwickler durch das Anbringen eines grünen Stickys auf einem Baustein eine minimale Anpassung. Daneben klebt eine Entwicklerin einen pinken Sticky mit der Notiz „Clients anpassen, Berechtigungsprüfung, Tests“ (Abb. 2). Offensichtlich schätzen beide die Komplexität der Anpassung anders ein. Im anschließenden Gespräch geht es nicht darum, richtig oder falsch zu unterscheiden. Vielmehr ist es entscheidend, zu verstehen, welche Annahmen zu den unterschiedlichen Einschätzungen geführt haben, um auf dieser Grundlage bessere Entscheidungen zu treffen:

Abb. 2: Annahmen explizit machen

Karl: „Das haben wir schon x-mal gemacht. Im Wesentlichen fügen wir dem API eine neue Methode hinzu. Je nach Berechtigung kann sie aufgerufen werden – fertig.“

Linda: „Das API müssen wir in jedem Fall anpassen. Das heißt aber auch, dass die bestehenden Clients angepasst werden müssen. Die Berechtigung muss clientseitig geprüft werden, und abhängig davon wird entschieden, welche Methode aufgerufen wird. Aktuell gibt es vier Clientsysteme. Die Integrationstests müssen erweitert werden, damit wir Seiteneffekte ausschließen können.“

Eva: „Ich habe dort gar keinen Zettel hingeklebt. Ich sehe die Änderung an anderer Stelle, eine Schicht tiefer im Backend. Da die Rolle des Nutzers schon heute übermittelt wird, ist das recht einfach und erfordert keine Änderung der Clients.“

Man kann sich gut vorstellen, wie die Diskussion nun weitergeht. Wichtig ist, dass nicht nur mehrere Lösungsansätze gegeneinander abgewogen werden. Gleichzeitig wird das Wissen über das System auf mehrere Personen verteilt. Karl sieht eine Chance auf eine einfache Lösung und möchte sie nutzen. Die Konsequenzen sind ihm zu diesem Zeitpunkt noch nicht vollständig bewusst. Linda hatte einen ähnlichen Gedanken, hat ihn aber bereits weitergedacht und Risiken erkannt. Karl profitiert von ihrer Perspektive, weil sein Blick über den konkreten Baustein hinaus erweitert wird. Eva bringt einen anderen, offenbar eleganteren Ansatz ein. Dass die Berechtigungsinformationen bereits übermittelt werden, war Karl und Linda bis dahin nicht bewusst.

Die exemplarische Szene zeigt, wie sich mentale Modelle durch Visualisierung (Abb. 3) und Reflexion einander annähern. Anders gesagt: Die Beteiligten entwickeln ein besseres gemeinsames Verständnis der Systemarchitektur, das über die konkrete Problemstellung hinausreicht. Davon profitieren alle, auch eher zurückhaltende Charaktere, die der Diskussion zunächst nur folgen, ohne selbst Zettel geklebt zu haben. Sie ebenfalls einzubinden und aktiv werden zu lassen, gehört zu den Aufgaben der Facilitator-Rolle.

Abb. 3: Storyboarding mit haptischen Betriebsmitteln

Varianten für Planung und Entscheidungsfindung

Je nach Fragestellung lässt sich die Praktik variieren. Das grundlegende Vorgehen bleibt gleich; verändert wird vor allem, welche Bedeutung die Ergänzungen auf den Sichten während der Session bekommen.

• Hotspots identifizieren: Die Teilnehmenden platzieren farbige Klebepunkte, um Änderungsbedarf an bestimmten Bausteinen zu signalisieren. Jede Farbe steht dabei für ein Änderungsszenario, etwa ein Feature, ein Backlog-Item oder einen Change. Das geht schnell und macht mögliche Hotspots sowie Überschneidungen zwischen den Szenarien sichtbar. Diese Variante eignet sich besonders für Planungssituationen, zum Beispiel als Grundlage für Aufwandsschätzungen. Das digitale Whiteboard in Abbildung 1 zeigt diese Variante.
• Lösungsalternativen finden: In dieser Variante arbeiten alle Teilnehmenden zunächst gleichzeitig, aber jeweils für sich: Sie platzieren Sticky Notes an den jeweiligen Bausteinen und notieren darauf, welche Änderungen sie für erforderlich halten. Dabei entstehen fast zwangsläufig Diskussionen über das Wesen der Änderungen und die zugrunde liegenden Annahmen, wie das obige Beispiel zeigt. Der Vorteil dieser Variante liegt darin, dass mehrere Ansätze früh sichtbar gemacht und gemeinsam bewertet werden können. Das Ergebnis der Session kann die bewusste Entscheidung für den erfolgversprechendsten Ansatz sein, festgehalten beispielsweise in einem ADR (Architecture Decision Record).
• Entscheidungsfindung: Diese Variante erfordert etwas mehr Vorarbeit, kann sich aber schnell auszahlen. Vorbereitet werden nicht nur Architektursichten, die den Istzustand beschreiben, etwa an einer Wand oder auf einem digitalen Whiteboard wie Miro. Zusätzlich werden aktuell diskutierte Lösungsoptionen bereitgestellt, die außerhalb der Session entstanden sind und für die noch eine Entscheidung aussteht. Diskutiert wird also – um im Bild aus der Theaterwelt zu bleiben – nicht nur eine einzelne Szene, sondern es geht um mehrere mögliche Varianten und ihre konkreten Auswirkungen. Zu Beginn erläutert eine teilnehmende Person, idealerweise nicht der/die Facilitator selbst, die Istsituation und die damit verbundene Problemstellung. Danach stellen die jeweiligen Urheber:innen ihre Optionen vor. Im weiteren Verlauf arbeitet die Gruppe an allen Darstellungen: Zettel und Punkte werden geklebt, Annahmen diskutiert und Details ergänzt. Ziel ist eine informierte Entscheidung, die aus mehreren Perspektiven geprüft wurde. Dafür kann es sinnvoll sein, den Teilnehmerkreis bewusst zu erweitern, etwa um Fachexpert:innen, Administrator:innen oder andere Spezialist:innen.

Die vorgestellten Varianten lassen sich abwandeln und miteinander kombinieren. Die Liste ist damit keineswegs abgeschlossen. Wertvolle Inspiration liefern Community-Veranstaltungen wie Barcamps, auf denen diese Praktiken diskutiert, ausprobiert und weiterentwickelt werden.

Architektur wird zum Team-Skill

Architekturarbeit zielt auf den langfristigen Erfolg eines Systems ab. Je besser ein Team die Qualitätsziele, die aktuelle Architektur und die verfügbaren Handlungsoptionen gemeinsam versteht, desto eher kann die Architekturarbeit von mehreren Personen getragen werden. Aufgaben, die bislang an einer einzelnen Person hingen, wandern ins Team. Das bedeutet nicht, dass alle dieselbe Erfahrung oder Expertise haben müssen. Nicht jede Person muss alles können. Aber Architekturentscheidungen müssen nicht mehr maßgeblich von einer einzelnen Person abhängen.

Weil beim Storyboarding mit Architektursichten gearbeitet wird, spielt die Dokumentation des Systems eine zentrale Rolle. Fehlt noch eine brauchbare Grundlage, wird vor der Session eine angemessene und schlanke Architekturbeschreibung für den konkreten Kontext erstellt. Ein angenehmer Nebeneffekt ist, dass die Arbeit mit den Sichten Lücken und Verbesserungspotenziale der vorhandenen Dokumentation aufzeigt. So kann sie kontinuierlich und pragmatisch weiterentwickelt werden. Durch Storyboarding wird Architekturdokumentation zu einem aktiv genutzten Werkzeug, statt nach ihrer Erstellung ungenutzt im Schrank zu verschwinden.

Die Rolle der Architekt:in wandelt sich

Die Rolle und die Aufgaben von Architekt:innen verändern sich unter technischen und organisatorischen Einflüssen. Neue technische Möglichkeiten wie agentische KI, kürzere Entwicklungszyklen und veränderte Formen der Zusammenarbeit wirken sich nicht nur darauf aus, wie Software entwickelt wird. Sie erhöhen auch den Druck auf Unternehmen und Teams, mit Marktveränderungen Schritt zu halten, ohne dabei mittel- und langfristige Qualitätseinbußen in der eigenen Architektur zu riskieren. Für Architekt:innen wird es deshalb immer wichtiger, selbst Facilitation-Skills aufzubauen.

Dabei geht es nicht nur um Moderation, sondern auch um Vorbereitung, Nachbereitung und Rahmenbedingungen:

• Wie schaffen wir die Voraussetzungen für eine erfolgreiche kollaborative Session?
• Welche Fähigkeiten oder welches Wissen fehlen dem Team, um eine tragfähige Lösung zu erarbeiten?
• Welches Ergebnis streben wir konkret an und wie wird daraus eine Entscheidung und schließlich Software?
• Welche organisatorischen und kulturellen Hürden gibt es? Welche Möglichkeiten haben wir als Team, sie zu senken?
• Was ist nötig, damit kollaborative Arbeit dauerhaft erfolgreich wird?

Diese Fragen müssen beantwortet werden, wenn kollaborative Arbeit mehr sein soll als ein einmaliges Experiment. Anknüpfungspunkte und Wissensquellen gibt es viele. Unter dem Kürzel COMO (Collaborative Modelling) hat sich eine lebendige Community [1] von Softwareschaffenden aus unterschiedlichen Bereichen gebildet, darunter viele bekannte Autor:innen und Vordenker:innen der Architekturszene. Dort werden genau solche Fragen diskutiert. Darüber hinaus gibt es Bücher [2] [3], Artikel, Veranstaltungen und Trainings, die sich mit dem kulturellen Wandel hin zu mehr Kollaboration und mit der praktischen Umsetzung beschäftigen.

Zusammenfassung und Ausblick

Collaborative Storyboarding ist eine leichtgewichtige Praktik, mit der Teams Architekturfragen gemeinsam bearbeiten. Dabei entsteht ein gemeinsames Verständnis der Architektur und der aktuellen Problemstellungen. Gleichzeitig wird eine schlanke Architekturdokumentation zu einem lebendigen, aktiv genutzten und gepflegten Artefakt.

Die Methode ist leicht zu erlernen und kann mit einer minimalen Architekturdokumentation niederschwellig eingesetzt werden. Fehlende Dokumentation wird im Zuge der Session-Vorbereitung schrittweise ergänzt. Collaborative Storyboarding bietet Teams und speziell Architekt:innen damit einen sanften Einstieg in kollaborative Architekturarbeit.

Das Aufgabengebiet von Softwarearchitekt:innen ist im Wandel. Äußere Einflüsse wie kürzere Umsetzungszeiträume durch agentisch unterstützte Softwareentwicklung und veränderte Marktlagen in vielen Branchen verändern auch die personellen Anforderungen. Kollaborative Architekturarbeit hilft, Architekturverantwortung auf mehrere Schultern zu verteilen. Konsequent angewendet, kann das zu einem echten Wettbewerbsvorteil werden. Es lohnt sich daher, das Potenzial kollaborativer Architekturpraktiken für die eigene Organisation auszuloten, kollaborative Sessions auf die Agenda zu setzen und Erfahrungen zu sammeln, um mit dem allgegenwärtigen Wandel Schritt zu halten.

Links & Literatur

[1] ComoCamp: Website der internationalen Collaborative-Modeling-Community und der gleichnamigen Unconference. https://comocamp.org

[2] Harmel-Law, Andrew: „Facilitating Software Architecture: Empowering Teams to Make Architectural Decisions“; O’Reilly Media, 2024

[3] van Kelle, Evelyn; Verschatse, Gien; Baas-Schwegler, Kenny: „Collaborative Software Design: How to Facilitate Domain Modeling Decisions“; Manning, 2024

[4] iSAQB e. V.: „Neues CPSA-Advanced-Level-Modul Kollaborative Softwaremodellierung (COSMO) veröffentlicht“: https://www.isaqb.org/de/news/neues-cpsa-advanced-level-modul-kollaborative-softwaremodellierung-cosmo-veroeffentlicht/