Beide Formate eignen sich um Projektbeteiligten IT-Mitarbeitern einen tiefen Einblick in die Fachdomäne geben und ein gemeinsames visuelles Modell der Domäne zu entwickeln. Dennoch haben beide Formate unterschiedliche Stärken und Schwächen, die ich in diesem Artikel herausarbeiten möchte. Evans schlägt hierzu die Entwicklung eines geteilten Domänenmodells als Brücke zwischen Domänenexperten und IT vor, welches in der Ubiquitären Sprache verfasst und durch den Applikationscode umgesetzt wird.
In den letzten Jahren haben sich für diese Tätigkeiten zwei moderne Workshopformate etabliert. Alberto Brandolini stellte 2013 sein “Event Storming” vor, das inzwischen die Welt im Sturm (Wortspiel nicht beabsichtigt) erobert hat. 2016 stellten Mitarbeiter der Firma Workplace Solutions ihr internes Format für Stakeholder-Interviews unter dem Namen “Domain Storytelling” der Öffentlichkeit vor.
Beide Formate eignen sich, um Projektbeteiligten IT-Mitarbeitern einen tiefen Einblick in die Fachdomäne zu geben und ein gemeinsames visuelles Modell der Domäne zu entwickeln. Dennoch haben beide Formate Stärken und Schwächen, die ich in diesem Artikel herausarbeiten möchte.
Was ist Domain Storytelling?
Schon lange bevor es IT-Systeme oder schriftliche Aufzeichnungen gab, waren Geschichten eine Form der Wissensvermittlung und Überlieferung der Menschheit. Wir sind Evolutionsbiologisch darauf getrimmt, Geschichten gut zu verinnerlichen. Das Domain Storytelling nutzt diese Tatsache aus, um zwischen Domänenexperten oder Nutzern eines IT-Systems und deren Entwicklern eine empathische Form der Wissensvermittlung zu etablieren.
Im Domain Storytelling Workshop wird ein Domänenexperte gebeten, die einzelnen Schritte, die er unternimmt um einen bestimmten Arbeitsablauf zu erledigen, anhand einer Geschichte am Beispiel zu erklären. Dabei wird eine Aufzeichnung der einzelnen Arbeitsschritte in Form von einfachen Piktogrammen festgehalten.
Diese Piktogramme verwenden eine Symbolsprache, um einen Workflow zu erklären. Diese Symbolsprache nennt sog. Actors (beispielsweise Benutzer oder Systeme), die eine Activity mit Hilfe von sog. Work objects (beispielsweise Dokumente, Formulare oder Datensätze) durchführen. Durch ein Lesen der Diagramme in der notierten Reihenfolge in Richtung der Pfeile, erzählen sie die Geschichte der Domänenexperten nach. Dabei sind die Bezeichnungen in den Piktogrammen aus der Domänensprache und bilden damit einen Anhaltspunkt für eine Unbiquitous Language.
Das folgende Beispielpiktogramm stammt von der Webseite domainstorytelling.org
Im Gegensatz zu anderen Prozessmodellierungsnotationen wird dabei aber nur eine einzelne beispielhafte Interaktion (etwa nur ein “Happy Case”) mit dem System formuliert und nicht alle möglichen Interaktionen mit allen möglichen Fehlerfällen.
Was ist Event Storming?
“Event Storming” ist nicht wie Domain Storytelling ein wohldefiniertes Format, sondern eigentlich eine Gruppe von verwandten Formaten mit Gemeinsamkeiten. Alberto Brandolini bezeichnet Event Storming deshalb gerne als Pizza: das Grundrezept, die lange Wand (“unlimited modelling space”), eine Unmenge an Klebenotizen (“unlimited sticky notes”) und zuletzt Menschen mit Fragen und Menschen mit Antworten, bleibt immer gleich. Das “Topping” unserer Pizza bestimmt dann den Schwerpunkt der Exploration.
Die bekanntesten beiden Schwerpunkte sind das “Big Picture” und das “Design Level”. Bei dem “Big Picture” wird ein kompletter Prozess von Anfang bis Ende auf hoher Flughöhe betrachtet und Pain Points oder Kontextgrezen identifiziert. Beim “Design Level” Format hingegen werden Implementierungsdetails wie Aggregategrenzen, aus den Domain Events abgeleitet. Daneben existieren noch weitere Formate mit Fokus auf UX, Wertströme, usw. Meiner Erfahrung nach wird aber Big Picture deutlich häufiger für ein Knowledge Crunching mit Domänenexperten angewendet, weshalb ich auf die anderen Formate nicht weiter eingehen möchte.
Zu Beginn des Formats wirft jeder Teilnehmer zunächst in einer massiv parallelen und chaotischen Phase seine subjektive Sichtweise auf die Domäne in Form von Klebezetteln “an die Wand”. Erst nach und nach werden Strukturen herausgebildet und die einzelnen mentalen Modelle der Teilnehmer zu einem “Großen Ganzen” zusammengeführt.
Dabei sind die entstehenden Strukturen emergent und müssen nicht den Modellen entsprechen, die die Teilnehmer vor dem Workshop im Sinn hatten. In dieser emergenten Phase wird auch Storytelling verwendet, um die Events entlang der Zeitleiste zu ordnen. Die Domänenexperten laufen hierzu entlang der Zeitleiste durch das Modell und versuchen es anhand eines Beispiels zu erklären, das jedoch nicht festgehalten wird. Das Wissen über die Domänen bleibt so den Teilnehmern des Workshops vorenthalten.
In großen Firmen wird aber der Prozess auch erstmals über Silogrenzen hinweg gesehen (ich zitiere einen meiner Kunden: “Endlich verstehe ich, was ihr da drüben tut!”). Dabei entstehen eine Menge interessanter Diskussionen über Richtigkeit, Notwendigkeit und andere Prozessdetails. Alberto bezeichnet dabei besonders kontroverse Stellen auch als “Hotspots”, die nicht im Laufe des Workshops geklärt oder aufgelöst werden können. Zum Abschluss des Workshops werden diese Hotspots, durch “arrow-” bzw. “dot voting” priorisiert und daraus weiterer Handlungsbedarf abgeleitet.
Dabei können besonders fatale Dysfunktionen und Flaschenhälse des Gesamtsystems zutage treten. Diese tiefgreifenden systemischen Probleme können dann offen angesprochen und Lösung versucht werden. In dieser Form angewendet, ist das Event Storming also viel mehr als nur eine Form des Knowledge Crunching. Es ist vielmehr eine Form der Therapie für dysfunktionale komplexe Systeme.
Wann setze ich was ein?
Beide Formate eignen sich durch ihren Fokus auf die Domäne und die eingängigen grafischen Notationen sehr gut dazu, eine Ubiquitäre Sprache und ein gemeinsames Modell der Domäne zusammen mit Domänenexperten zu entwickeln. Es bleibt aber die Frage, wo liegen die jeweiligen Stärken der Formate?
Event Storming scheint mir eine für innovative, disruptive und stark dysfunktionale Domänen sehr effektive Methode zu sein, um neue, emergente Strukturen und Ideen zu entwickeln (für Kenner des Cynefin-Modells: wir bewegen uns im Event Storming aus der kreativen “Chaotic” Domäne langsam zu “Complex”, wo wir neue Lösungen entstehen sehen) oder organisatorische Dysfunktionen für alle Beteiligten sichtbar herauszuarbeiten.
Das Event Storming glänzt darüber hinaus mit seinen vielen, zugegeben noch zum Zeitpunkt dieses Artikels recht schlecht dokumentierten, Varianten, die auch zu anderen Zwecken, wie der Modellierung von Aggregates, der Analyse von UX etc., verwendet werden können. All das macht das Format sehr vielseitig.
Das Domain Storytelling hingegen hat durch das gut verständliche Artefakt in Form der Piktogramme ganz eindeutig überall dort die Nase vorn, wo eine schriftliche Dokumentation der Prozesse gefordert ist. Vielleicht ist das auch ein Grund dafür, dass die Akzeptanz des Domain Storytellings meiner Erfahrung nach vor allem bei Teilnehmern, die einen starken Hintergrund in dokumentenlastigen Prozessen haben, höher ist, als beim Event Storming.
Ein solcher Storytelling Workshop kann auch gut aufgezeichnet werden und dadurch für die Nachwelt als weitere Form der Dokumentation des Domänenwissens dienen. Das Event Storming ist für eine Aufzeichnung zu chaotisch und das entstandene Modell oft überwältigend für jemanden, der bei dessen Entstehung nicht mitgewirkt hat.
Ein weiterer Punkt geht an das Domain Storytelling, wenn in stark verteilten Teams gearbeitet wird. Hier kann Event Storming nicht angewandt werden, während das Storytelling sehr gut auch über Videokonferenzsysteme funktioniert.
Beiden Formate ist gemeinsam, dass sie dabei helfen können, um Kontextgrenzen in Systemen zu finden. Wobei das Event Storming meiner Meinung nach hier gefühlt schneller zu einem Ergebnis führt, als die Auswertung aller Piktogramme des Domain Story Tellings.