Event Storming ist ein kollaboratives Workshop-Format, das Teams dabei unterstützt, ein tiefes Verständnis von Geschäftsprozessen und -anforderungen zu entwickeln. Es kann helfen, komplexe Probleme zu identifizieren und Lösungen zu finden. Das Ziel dieses Artikels ist es, Ihnen eine Einführung in Event Storming zu geben, einschließlich der Grundlagen des Formats, wie man eine Session durchführt und bewährte Verfahrensweisen für die Nutzung von Event Storming. Alberto Brandolini ist der Erfinder dieser Methode. Lese weiter, um mehr darüber zu erfahren!
Einleitung, Übersicht & Zusammenfassung
In einem ein- oder zweitägigen Event kommen Menschen zusammen, um fachliche Ereignisse zu modellieren. Also das, was ein System leisten kann (z.B. eine Webseite mit einem Shop System), steht im Mittelpunkt und dazu sprechen alle Menschen mit einer einfachen Notation und schaffen das Verständnis dazu. Damit das im eigenen Kontext gut klappt, braucht es beim Eventstorming eine gemeinsame Sprache und auch eine gemeinsame Notation.
Ist diese Vorbereitung klar, kommen die Menschen zusammen und arbeiten über die festgesetzte Zeit - ohne Tische und ohne Stühle, meist an einer Wand auf der die Events chronologisch festgehalten werden. Der verlauf des Workshops ist sehr geprägt von Interaktion und Diskussion. Durch diesen kollaborativen Ansatz im Domain-Driven-Design (DDD) sprechen die Menschen durch diese Methodik zusammen
Das Ergebnis des Event Storming ist dann ein gemeinsames Bild aller Beteiligten auf das System. Die Vorteile liegen auf der Hand: Ist die Klarheit & das Verständnis vorhanden, lässt sich ein System viel besser entwickeln und Silos werden abgebaut und alle Stakeholder sind eingebunden. In Scrum kann daraus dann das Backlog mit einem Story Mapping erarbeitet werden.
Quelle: YouTube. beim Klicken verlässt du meine Plattform bzw. werden Daten an YouTube übermittel. Weitere Informationen findest du in der Datenschutzerklärung.
Die Modellierung beim Event Storming
Bei Event Stormings arbeiten wir Post-Its (Klebezettel) und bringen das gesamte Team zusammen. Es geht um die Wissenstransfer zwischen Fachexperten, Stakeholdern, Product Owner und weiteren Menschen, die fachlich auf Geschäftsprozesse zu schauen und denen, die es entwickeln (Entwickler). Es geht immer um das gemeinsame Verständnis. Dazu hast du für deinen Workshop eine Papierrolle (oft brown paper), die mehrere Meter lang ist (10 Meter kann sich als sehr hilfreich erweisen) besorgt und an eine gute Moderation gedacht.
Orange - Domain Events
Organe: Blaue Notizzettel repräsentieren Domain Events - Aktionen oder Ereignisse, die in einem System auftreten können. Es handelt sich um Handlungen, bei denen Daten erstellt oder aktualisiert werden, beispielsweise Bestellungen aufgeben oder Zahlungen leisten. Wir verwenden hier immer die Vergangenheitsform.
Blau - Aktivitäten
Blau: Gelbe Notizzettel stehen für die Aktivitäten (Command) und Prozesse, die von den Benutzern des Systems durchgeführt werden. Diese schreiben wir in der Gegenwart.
Rot - Risiken
Rot: Rote Notizzettel können verwendet werden, um Risiken oder Probleme hervorzuheben, auf die während einer Event Storming Session gestoßen wird.
Hellgelb - Aggregate
Hellgelb: Wir stellen “Aggregate” (eine Gruppe von zusammenhängenden Entitäten, die eine konsistente Einheit bilden) mit hellgelb dar. Im Allgemeinen ist es wichtig, Aggregates so zu definieren, dass die Konsistenz der Daten innerhalb des Aggregats sichergestellt wird und gleichzeitig die Abhängigkeiten zwischen verschiedenen Aggregaten minimiert werden. Dadurch wird die Skalierbarkeit des Systems verbessert und gleichzeitig sichergestellt, dass alle Geschäftsregeln korrekt umgesetzt werden. Sie sind das zentrale Konzept bei der Arbeit mit Event Storming und helfen dabei, ein besseres Verständnis für die Struktur und Beziehungen innerhalb eines Systems zu erhalten.
gelb - Akteure
Gelb: Die Akteure des Systems werden oft auf gelben Zetteln festgehalten. Wenn du eine gute Unterscheidung zu den Zettel zuvor brauchst, achtest du am besten auf eine deutliche Farbunterscheidung oder nutzt ein kleines Bild eines Akteurs.
Grün - Daten und Informationen
Grün: Sind die Daten und Informationen, die wir brauchen "Read Model". Das sind die Daten, die ein Akteur in seiner Aktion meistens benötigt, um eine Entscheidung treffen zu können.
Lila - Policies
Lila: Lila Notizzettel repräsentieren Policies - Regeln oder Bedingungen, die auf bestimmte Events angewendet werden müssen.
Hinweis
Du musst natürlich nicht zwingend die Farben sein, wichtig ist nur deine Legende, damit alle Teilnehmer wissen wofür die Farben stehen.
Event Storming Workshop: Kollaborativ die Requirements modellieren
Der Ablauf in einem Event Storming Workshop ist oft chronologisch von links nach rechts auf dem Brown Paper. Dabei wird die Wandfläche visuell immer voller und voller. Damit alle Teilnehmer alles gut verstehen eignet sich ein Big Picture, d.h. ein Bild auf dem alle Farben und Begriffe gelistet sind.
Das unterstützt absolut auch das Ergebnis des Workshops. Das Bild ist oft trivial, der Weg dahin nicht. Neben einer guten Moderation, den richtigen Materialien und natürlich den richtigen Menschen ist das Big Picture ein wichtiger Baustein.
Domain Event
Beginnen wirst du immer mit den sogenannten Domain Events. Diese hast du oben schon kurz kennengelernt. Diese in der Vergangenheit geschrieben Events werden normalerweise auf orangenen Klebezetteln notiert. Das sind Ereignisse, die Menschen aus der Anwendung und dem Fachbereich auf jeden Fall kennen. Mittels Event wird so ausgedrückt, was in der Fachdomäne passiert.
Beispiel: Warenkorb wurde aktualisiert.
Command / Aktion
Die Commands oder Aktionen sind eng zusammenhängend mit den vorherigen Domain Events. Denn das Ergebnis einer Aktion ist immer ein solches Domain Event.
Beispiel: Waren in den Warenkorb legen.
Akteur
Die oft per Strichmännchen gezeichneten User in einem System werden auf gelben Klebezetteln festgehalten. Das sind die Menschen, die mit dem System interagieren. Sie lösen auch ein Kommando und führen Befehle aus.
Beispiel: Webseitenbesucher / Kunde
Aggregate
In der Regel repräsentiert ein Aggregate eine Geschäftsregel oder einen Prozess im System. Das ist eine Gruppe von zusammenhängenden Elementen, die eine Einheit bilden.
Ein Beispiel könnte ein Online-Shop sein. Der “Order”-Aggregate könnte aus den Entitäten “Order”, “Customer”, “Product” und “Payment” bestehen. Diese Entitäten sind eng miteinander verbunden und bilden zusammen einen Bestellvorgang im System ab.
Externe Systeme
Externe Systeme sind alle Systeme oder Prozesse, die außerhalb des betrachteten Systems liegen. Diese können beispielsweise andere Systeme sein, mit denen das betrachtete System kommuniziert oder Schnittstellen hat. In der Event-Storming-Modellierung würden wir dies dadurch darstellen, dass wir ein neues Sticky Note erstellen und es mit einem Pfeil an das Haupthandlungssystem anschließen. Auf dieser Notiz würden wir dann alle relevanten Informationen über das externe System notieren.
Ein Beispiel für ein externes System im Event Storming könnte ein Payment Gateway sein. Wenn wir einen Online-Shop modellieren, würde das Payment Gateway als externes System betrachtet werden. Es interagiert mit dem Online-Shop und erbringt eine wichtige Funktionalität (in diesem Fall Zahlungen), aber es ist nicht Teil des Kernsystems.
Bounded Context, Subdomäne, Kontext
Im Event Storming ist ein “Bounded Context” ein abgegrenzter Bereich innerhalb eines Geschäftsprozesses oder einer Domain. In diesem Bereich existieren bestimmte Regeln und Bedingungen, die von anderen Bereichen abweichen können. Die Idee dahinter ist es, dass komplexe Geschäftsprozesse in kleinere, überschaubare Teile unterteilt werden können. Dadurch wird es einfacher, diese Teile zu verstehen und zu bearbeiten.
Ein Beispiel für einen Bounded Context könnte eine E-Commerce-Website sein. Innerhalb dieses Kontextes könnte es verschiedene Teilbereiche geben, wie z.B. das Bestellmanagement (Warenkorb) oder das Kundenkonto-Management. Jeder dieser Bereiche hat seine eigenen Regeln und Bedingungen.
Policies
Policies dienen dazu, Regeln für den Ablauf der Prozesse festzulegen. Diese entstehen durch Gespräche mit den Stakeholdern über den Tag.
Ein Beispiel: Angenommen, Sie planen ein Online-Shopping-System, bei dem Kunden eine Bestellung aufgeben können. In diesem Fall könnte eine Regel (Policy) lauten, dass eine Bestellung nur dann bearbeitet werden kann, wenn sie vollständige Informationen enthält (beispielsweise Lieferadresse und Zahlungsmethode).
Durchführung einer Event Storming Session
Fazit: Modellierung beim Event Storming
Insgesamt kann man sagen, dass Modellierung beim Event Storming ein äußerst nützliches Werkzeug ist. Durch die visuelle Darstellung von Geschäftsprozessen und -regeln können komplexe Zusammenhänge veranschaulicht und besser verstanden werden. Außerdem ermöglicht es eine effiziente Zusammenarbeit zwischen verschiedenen Abteilungen und fördert so die Innovation im Unternehmen. Wenn du also noch nicht mit dem Event Storming begonnen hast, solltest du es auf jeden Fall in Betracht ziehen!