EventStorming ist ein Verfahren in Form eines Workshop, um herauszufinden, was in einer Domäne passiert. Die Methodik geht auf Alberto Brandolini zurück und fand im Jahr 2012 ihren Anfang. EventStorming wurde im Kontext von Domain-driven Design entwickelt und kann als ein Teil davon betrachtet werden.
Der Begriff EventStorming drückt in Anlehnung an das Brainstorming aus, dass die Domäne gemeinsam ohne besondere Vorbereitung der Teilnehmer erarbeitet wird, indem Events spontan herausgestürmt werden. EventStorming ist neben anderen Methoden wie User Story Mapping, Impact Mapping und Domain Storytelling eine Form des Collaborative Modellings: Es ist eine Gruppenleistung, die dadurch entsteht, dass Menschen mit den für das Thema erforderlichen Kompetenzen sich in einem Raum treffen und das Zielbild gemeinsam erarbeiten.
Ziele
EventStorming hilft allen Beteiligten, eine Domäne besser zu verstehen. Entwickler erlangen so die Möglichkeit, Geschäftslogik nachhaltig in Code zu übersetzen, also Prozesse zu digitalisieren und dabei die richtigen Entscheidungen zu treffen. Durch gezielte Fragen und die gemeinsame Modellierung können Ungereimtheiten und Stolpersteine frühzeitig erkannt und beseitigt werden. Komplexe Abläufe, die bisher allen nur in Teilen bekannt waren, können zu einem vollständigen Bild zusammengesetzt und transparent gemacht werden. Der Austausch aller Beteiligten führt zu einem gemeinsamen Verständnis – auch für einander. EventStorming bietet die Chance, aus Silos auszubrechen und gemeinsame Begrifflichkeiten zu etablieren. Letzteres ist für die Kommunikation, für Abstimmungen und Commitments essenziell, denn oftmals existieren in einer gewachsenen Domäne mehrere Begriffe für das Gleiche, und gleiche Begriffe für verschiedene Dinge.
Vorbereitung
Ein erfolgreiches EventStorming bedarf der richtigen Teilnehmer. Das sind zum einen diejenigen Personen, die die richtigen Fragen stellen, und zum anderen die mit den passenden Antworten darauf. Zu Ersterem zählen vorwiegend Entwickler; also die Personen, die sich die Domäne noch im Detail erschließen müssen. Letzeres umfasst die Domänenexperten, welche typischerweise die Stakeholder und Product Owner sind. Auch Entwickler können mit der Zeit selbst zu Domänenexperten werden.
Je größer die betrachtete Domäne ist, desto mehr können auch Domänenexperten zu den Fragen beitragen, da Menschen aus unterschiedlichen Fachbereichen verschiedene Sichtweisen mitbringen. Hierbei zahlen sich die Konzepte des Domain-driven Designs aus, etwa Subdomains und Bounded Contexts zu identifizieren und gemeinsam darüber zu sprechen.
Der Workshop sollte von einer Person, die sich inhaltlich nicht beteiligt und mit der Methode vertraut ist, moderiert werden. Der Moderator kann steuernd eingreifen, wenn es mal stockt oder die Teilnehmer sich verzetteln.
Die Anzahl der Teilnehmer liegt optimalerweise bei um die acht und sollte 15 nicht übersteigen. Der Grund dafür ist, dass EventStorming eine Gruppenarbeit ist, in die sich jeder einbringen darf. Bei zu vielen Beteiligten kann sich nicht mehr jeder aktiv einbringen oder es kommt zur Bildung kleinerer Gruppen, die dann zwar in regem Austausch sein mögen, ihr ausgetauschtes Wissen aber nicht mehr vollständig in die große Gruppe zurücktragen.
So wichtig wie die Menschen ist auch der Raum. Er sollte viel Platz und möglichst keine Sitzgelegenheiten bieten. Tische und Stühle sollten also in die Ecke gestellt werden. Ein Tisch wird zur Ablage des Arbeitsmaterials verwendet. Als Arbeitsfläche dient eine möglichst große Wand. Um die zehn Meter in der Breite sind angemessen. Damit die Sticky Notes, mit denen im Wesentlichen gearbeitet wird, besser halten, und das Ergebnis nicht nur abphotographiert, sondern auch zusammengerollt mitgenommen werden kann, bietet sich Meterware wie Brown-Paper als Untergrund an der Wand an. Sticky Notes sollten „unendlich“ in verschiedenen Farben zur Verfügung stehen. Acht Farben sollten vorhanden sein, zur Not kann auch über Formen und Größen differenziert werden. Jeder Teilnehmer sollte mindestens einen Stift dauerhaft zur Hand haben.
Durchführung
EventStorming ist ein iterativer und explorativer Prozess. In den ersten Phasen mögen viele Karten entstehen, die später nochmal überarbeitet, anders angeordnet oder sogar wieder entfernt werden. Aus diesem Grund ist es entscheidend, mit Karten zu arbeiten und nicht auf das Untergrundpapier selbst zu schreiben, denn dann wird es unübersichtlich, wenn später Korrekturen stattfinden. Grundsätzlich sollte jeder ermutigt werden, am Prozess teilzunehmen und seine Sicht der Dinge zu schildern. Wird der Workshop von einigen wenigen dominiert, könnte am Ende ein verzerrtes Bild der tatsächlichen Domäne entstehen. Die folgenden Phasen müssen nicht strikt in dieser Reihenfolge und Ausgestaltung stattfinden, sondern stellen vor allem ein Beispiel dar, wie man sich iterativ, „in kleinen Schritten“, der Gesamtdomäne nähern kann.
„Event Storming“
Zu Beginn ist es das Ziel, möglichst alle Events der Domäne zu identifizieren. Events sind domänenrelevante Ereignisse, die zu einem Zeitpunkt stattgefunden haben. Sie werden daher in der Vergangenheitsform formuliert und bestehen üblicherweise mindestens aus einem Nomen und Verb. Events sollten in der Sprache der Domäne formuliert sein. Ereignisse, die nicht domänenrelevant sind, sollten auch nicht erfasst werden. Die meisten Domänen sind nicht technisch geprägt und Events wie „Order-Service angefragt“ oder „Kafka-Nachricht versendet“ keine domänenrelevanten Ereignisse. Die Technik ist an dieser Stelle ein Implementierungsdetail und kann sich unabhängig von der fachlichen Domäne ändern, insofern sollte man vermeiden, sie im im Event Storming entstehenden Bild unterzubringen. Stattdessen sollten die Beteiligten sich die Frage stellen, warum der Order-Service angefragt oder die Kafka-Nachricht versendet wurde. Wenn diese Aktionen fachlich relevant sind, so stecken vermutlich domänenrelevante Ereignisse dahinter, etwa „Bestellstatus geprüft“ oder „Bestellung abgeschlossen“.
Die Domain Events stellen das Grundgerüst des am Ende entstehenden Bilds dar. Die weiteren Bausteine leiten sich von diesen Events ab. Natürlich kann man in den späteren Phasen noch neue Events identifizieren und ergänzen, aber es hilft ungemein, wenn man direkt zu Beginn möglichst viele Events aufdeckt. Daher kann es ein guter Ansatz sein, dass jeder Teilnehmer für sich in einer zeitlich begrenzten stillen Phase alle ihr oder ihm bekannten Events zu Papier bringt und diese in einem nächsten Schritt in der Gruppe konsolidiert werden. Ein Vorteil davon ist, dass sich so wirklich jeder einbringt und auch Events auf den Tisch kommen, die vielleicht nur ein oder zwei eher zurückhaltende Teilnehmer im Kopf haben und sonst nicht geäußert hätten. Ein Nachteil dieser Vorgehensweise ist, dass dabei viele Duplikate entstehen.
Konsolidierung
Die gesammelten Events werden dann an der Arbeitsfläche angebracht. Dabei wird die Richtung von links nach rechts als Zeitskala betrachtet, so dass sich Geschäftsabläufe in dieser Lesrichtung darstellen lassen. Hierbei ist es essenziell, auf die richtige Formulierung zu achten, also ein Event als ein bereits stattgefundenes Ereignis zu formulieren und fachlich anerkannte Begriffe zu verwenden oder darauf hinzuarbeiten, sich auf gemeinsame Begrifflichkeiten zu einigen („Reden wir von einem Produkt, oder einem Artikel, oder einem Item?“).
Event-Ursachen und -Folgen
Jedes Event hat einen Auslöser und jedes Event löst etwas aus. Meistens sind beide domänenrelevant und oftmals besteht auch keine Eins-zu-Eins-Beziehung. In einem zweiten Schritt führen wir weitere Bausteine ein.
Commands (Befehle) sind das Pendant zu Events. Während Events zum Ausdruck bringen, dass etwas bereits (erfolgreich) stattgefunden hat, beschreiben Commands eine Aktion, die ausgeführt werden soll. Ein Command kann mehrere Events zur Folge haben.
Actors (Aktoren / ausführende Personen) führen Commands aus, indem sie z.B. per Mausklick einen Artikel in den Warenkorb ablegen oder per Klick auf einen „Jetzt kaufen“-Button verbindlich bestellen.
Business Processes oder Policies (Geschäftsprozesse / fachliche Vorgaben) sind automatisierte Prozesse, die Commands ausführen oder als Seiteneffekte aus Commands heraus wirken. Eine Policy könnte sein, dass zehn Tage nach aufgegebener Bestellung ohne Zahlungseingang ein Mahnverfahren angestoßen wird, oder dass ein Kunde nach Bearbeitung einer Bestellung im Versandlager über den Versand der Ware automatisch informiert wird.
Verfeinerung
Nun wo die Domain Events identifiziert und in einen zeitlichen Zusammenhang gebracht worden sind, ihre Auslöser und Folgen verbildlicht sind, gibt es ein paar weitere Bausteine, mit denen die Domäne noch greifbarer gemacht werden kann.
Externe Systeme klingen auf den ersten Blick technisch, sind aber aus fachlicher Motivation heraus in die Domäne eingebunden und können als Teil von ihr in das Bild mit aufgenommen werden. Dabei kann es sich beispielsweise um Zahlungsdienstleister, Versanddienstleister, externe Software für einen Teil des Systems wie etwa eine Kassensoftware usw. handeln.
Aggregates (Aggregate) sind ein Begriff aus dem Domain-driven Design und bezeichen zusammengesetzte Entitäten. Je nach Domäne kann ein Aggregat zum Beispiel eine Bestellung, ein Auftrag, ein Produkt oder ein Benutzerkonto sein. Aggregate stehen im Kontext von Commands und Events, entstehen dabei, werden aktualisiert, gelöscht, oder verändern ihren Aggregatzustand. Eine Bestellung kann etwa eingegangen, bearbeitet, versandfertig oder versandt sein, was jeweils mit einem Event versehen und durch Policies oder manuelle Bearbeitung durch Aktoren weitere Commands nach sich ziehen kann. Aggregate sind wertvolle Informationen für Entwickler, die das Domänenmodell verstehen und in Code übersetzen müssen.
Das Read Model, manchmal auch als View bezeichnet, ist die Sicht eines Aktoren auf ein System, um Commands auszuführen. Dabei kann es sich etwa um eine Anmeldemaske, einen Registrierungsbildschirm, einen Suchschlitz, einen Warenkorb oder eine Bestellübersicht handeln. Read Models haben keine Eins-zu-Eins-Beziehung zu Commands, schon deshalb lohnt sich die Differenzierung. Der Aufruf einer Seite mit preisreduzierten Artikeln könnte etwa von der Seite selbst über Navigationselemente oder eine integrierte Suche erfolgen, aber ebenso aus einem Link in einem Newsletter oder einer Werbeanzeige auf einer anderen Seite heraus. Domänenexperten kommunizieren oft über diese Read Models und so können sie signifikant zum gemeinsamen Verständnis über die Domäne beitragen.
Stolpersteine
In verschiedenen Phasen des Workshops können Ungereimtheiten auftauchen oder verschiedene Meinungen aufeinanderprallen. Damit die Teilnehmer das übergeordnete Ziel im Blick behalten und sich nicht in Detaildiskussionen verlieren, können solche Bereiche mit einem Hot Spot versehen werden. Ein solcher Sticky Note sagt dann aus „hier gibt es noch Unstimmigkeiten“, aber zugleich „wir nehmen das mit und klären das nach dem Workshop“.
Farbkodierung und Beispiele
Mir sind keine offiziellen Farben zu den Bausteinen des EventStormings bekannt, jedoch haben sich die folgenden Farben vielfach durchgesetzt und bilden ein solides Fundament. Sollte die ein oder andere Farbe nicht zur Hand sein, kann man auch mit unterschiedlichen Größen und Formen arbeiten (quadratisch, Querformat, abgerundet…).
- Domain Event: orange
- Command: blau
- Actor: neongelb
- Business Process / Policy: lila
- Read Model / View: grün
- Aggregate: kanariengelb
- Externes System: rosa
- Hot Spot: rot
Die folgenden Beispiele sind rein fiktiv und bewusst vereinfacht. Sie sollen nicht zeigen, wie ein Event Storming ablaufen muss, sondern wie es ablaufen kann. Der Ablauf hängt von diversen Faktoren ab: Von der Größe der Domäne, der Expertise der Domänenexperten, der Erfahrung aller Mitwirkenden mit dem Format EventStorming etc.
Im ersten Schritt werden Events gesammelt und unsortiert auf der Arbeitsfläche angebracht. Das Ergebnis ist in dieser Phase noch unbewertet. Es gibt Duplikate, noch zu verbessernde Benennungen und auch Karten, die eher ein Command als ein Event beschreiben.
Im zweiten Schritt wird über die Karten gesprochen. Duplikate und unpassende Karten werden entfernt, Bezeichnungen angepasst und die Events in einen zeitlichen Zusammenhang gebracht.
Im dritten Schritt machen wir uns Gedanken darüber, welche Befehle zu den Ereignissen führen und welche diese wiederum zur Folge haben.
Im vierten Schritt denken wir darüber nach, wo die Commands ihren Ursprung haben, wo menschliche Akteure im Spiel sind und wo automatisierte Prozesse greifen.
Am Ende ergibt sich ein Bild, mit dem alle Teilnehmer des Workshops zufrieden sind. Neben den Akteuren sind die Read Models bekannt, aus denen heraus die Commands umgesetzt werden. Mehrere Hot Spots wurden identifiziert, die einzelne Teilnehmer als Aufgaben aus dem Workshop mitnehmen. Für verschiedene Commands wurden die zentralen Aggregate identifiziert und drei für die Prozesse wesentliche externe Systeme wurden ausgemacht. Der gesamte Ablauf streckt sich über fünf Bounded Contexts, die am Ende um die Bausteine herum auf das Untergrundpapier gemalt und benannt wurden.
Fazit
EventStorming ist ein Super-Format, um sich eine Domäne gemeinsam mit unterschiedlichen Kompetenzträgern zu erschließen. Die Methode regt zum intensiven Austausch und Storytelling an und offenbart somit viel mehr, als Interviews bzw. Einzelgespräche zwischen einem Entwickler und einem Domänenexperten. Ein offener, respektvoller und gut moderierter Umgang sowie ein guter Raum, ausreichend Materialien und genügend Zeit sind entscheidend, um zu einem guten Ergebnis zu kommen. Statt über lange Zeit einzelnen Wissensträgern Informationen „aus der Nase zu ziehen“ und Missverständnisse erst nach viel hin und her und mit einer gewissen Restunsicherheit aus dem Weg zu räumen, hat EventStorming das Potenzial, an nur einem Nachmittag ein wirklich stimmiges Bild zu schaffen.
Damit jeder abgeholt und mitgenommen wird, sollte man auf Sitzmöglichkeiten verzichten und durch viel Freiraum den Weg zu den Arbeitsmaterialien und zur Arbeitsfläche so angenehm wie möglich machen. Wer sich durch enge Gänge zwischen Tischen und Stühlen navigieren muss, ist weniger ermutet, auch seinen Teil zum Gesamtbild beizutragen. Gerade wenn Teilnehmer dieses Format zum ersten Mal erleben, lohnt es sich, mit einer Legende zu arbeiten. Der Einsatz von Sticky Notes erlaubt es, dass keine Karte in Stein gemeißelt ist und alles jederzeit verschoben oder neu geschrieben werden kann.
Zwar halte ich ein Vor-Ort-EventStorming mit Sticky Notes für die bessere Alternative, jedoch kann EventStorming auch (mit einer guten Portion Disziplin) remote durchgeführt werden. Dazu bieten sich Whiteboard-Softwarelösungen wie Miro oder Mural an.
- 50000 orange stickies later (Präsentation von Alberto Brandolini zum EventStorming, 2017)