Collaboration Whiteboard Tooling

Systemzweck

Komplexe Architektur ("Sociotechnical Architecture") entsteht nicht im stillen Kämmerlein durch das Tippen von "UML" in ein Textfile. Komplexe Systeme müssen von Domänen-Experten, Business-Ownern und Architekten gemeinsam, gemeinsam entwickelt werden. Wenn Teams in verschiedenen Zeitzonen (Remote Work) sitzen, ist ein physisches Whiteboard mit Post-its oft nicht mehr ausreichend. Collaboration Whiteboard Tooling (z.B. Miro, Mural, FigJam) stellt einen unbegrenzten, multi-player "Canvas" zur Verfügung. Es schließt die Delay-Lücke (Synchronisations-Verzögerung) in der Architekturplanung fast auf den Nullpunkt in Echtzeit.

Mechanik des Werkzeugs

Diese Werkzeuge bestechen durch deutliche Simplizität. Im Gegensatz zu hochkomplexen CAD- oder SystemDynamics-Programmen gibt es keine steile Lernkurve. Jeder Teilnehmer kann sofort ein Post-It erstellen, Pfeile ziehen, farblich markieren oder gruppieren. Die wichtigste Mechanik ist die stark geringe Eintrittsbarriere für "Non-Technical" Stakeholder (Die Leute, die die Business-Domäne wirklich verstehen). Durch Maus-Zeiger-Bewegungen (Live-Cursors) entsteht eine kollektive Fokus-Hypnose (Gemeinsamer mentaler Raum).

Architektur-Einsatz

1.Event Storming (Domain-Driven Design): 20 Entwickler und 5 Sales-Spezialisten betreten das Board und werfen hunderte gelbe Post-Its (Events) in einer zeitlichen Abfolge auf das unbegrenzte digitale Papier, um die Grenzen (Bounded Contexts) zukünftiger Microservices deutlich zu erzwingen.

2.Wardley Mapping: Das Management zeichnet live Wertschöpfungsketten-Graphen, um konsequent zu entscheiden, welche Cloud-Dienste sofort an Google outgesourced werden müssen (Utility) und welche das Team selbst coden muss (Genesis).

Grenzen und Gefahren

"The Unstrukturierte Workshop-Ergebnisse" (Unstrukturierte Workshop-Ergebnisse). Ein digitales Whiteboard ist nach einem 4-stündigen Architektur-Workshop meist ein unübersichtliches Arbeitsfeld aus 5.000 Post-Its, unverbundenen Pfeilen und verworfenen Gedankensplittern. Wenn dieses Arbeitsfeld nicht in den letzten 30 Minuten des Meetings zwingend durch die Lead-Architekten in klare "Architecture Decision Records" (ADRs - Text) übersetzt (destilliert) wird, ist die gesamte Arbeit des Whiteboards schwer nutzbar. Ein Screenshot eines verworrenen Miros ist kein Systemdokument.

Diagramm

Abgrenzung

Causal Loop Tools (CLD) erzwingen grammatische Korrektheit (Graphen). Collaboration Whiteboards sind formlos (Agnostic). Du kannst zeichnen, was immer das Systemdenken im Moment erfordert, opferst dafür aber jegliche maschinelle Analyse-Sicherheit (Das Werkzeug wird dich nie warnen, wenn deine Architektur strukturell unwahrscheinlicher ist).

Entscheidungs- und Praxisleitfaden

Achte konsequent auf Timeboxing (Striktion der Zeit) und Governance. Für ein Event Storming Board auf Miro benötigst du Templates, in denen eine rote Karte immer exakt einen Befehl, eine blaue immer ein System und eine grüne Karte immer einen Read-Model-State bedeutet. Ohne im Voraus definierte visuelle "Syntax" wird das Whiteboard sofort in ein bedeutungsloses Kunstprojekt entarten, dem jegliche Entscheidungs-Wirkung fehlt.

Quellen

Miro — Online Collaborative Whiteboard

Alberto Brandolini — Introducing EventStorming (Leanpub, 2021)

Simon Wardley — Wardley Maps (Online-Buch)