Collaboration Whiteboard Tooling

Systemzweck

Die meiste 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, lebendig geformt werden. Wenn Teams in verschiedenen Zeitzonen (Remote Work) sitzen, ist das physische Whiteboard mit klebrigen Post-Its tot. *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 brutale 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 extrem 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 brutal zu erzwingen.

2.Wardley Mapping: Das Management zeichnet live Wertschöpfungsketten-Graphen, um radikal 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 Graveyard of Chaos" (Der Friedhof des Chaos). Ein digitales Whiteboard ist nach einem 4-stündigen Architektur-Workshop meist ein unleserliches Trümmerfeld aus 5.000 Post-Its, unverbundenen Pfeilen und verworfenen Gedankensplittern. Wenn dieses Müllfeld nicht in den letzten 30 Minuten des Meetings *zwingend* durch die Lead-Architekten in harte "Architecture Decision Records" (ADRs - Text) übersetzt (destilliert) wird, ist die gesamte Arbeit des Whiteboards im Nichts verpufft. 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 physikalisch unmöglich ist).

Entscheidungs- und Praxisleitfaden

Achte gnadenlos 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)