Dieser Blogpost soll einen kurzen Überblick zum Thema Event Storming geben, um zu klären, worum es sich dabei handelt und wie diese Methode besser (nicht) genutzt wird.
Was ist Event Storming?
Event Storming ist ein Workshopformat, das 2013 von Alberto Brandolini erarbeitet und bekannt gemacht wurde. Es ist ein Hilfsmittel, um Fach- und Implementierungsexperten über die abzubildende Domäne diskutieren zu lassen, mit dem Ziel die wichtigsten Domänenobjekte und deren Wechselwirkungen herauszuarbeiten. Das genaue Vorgehen kann in der Praxsis stark variieren und hängt dabei sowohl von den Erfahrungen der Moderierenden als auch dem tatsächlichen Ziel des Workshops ab.
Der erste Schritt eines Event Storming Workshops besteht darin, die auftretenden Domänenereignisse zu ermitteln und sie in eine chronologische Reihenfolge zu bringen. Dies ist dann auch der „Trick“ über den der Austausch zwischen den verschiedenen Experten gefördert wird. Denn diese Ereignisse gehören eindeutig zur Beschreibung des Problemraums und nicht zum Lösungsraum, wodurch sich alle Teilnehmenden an der Domäne orientieren müssen, bevor sie zu einem späteren Zeitpunkt in die Detaillösungen absteigen.
Nach den Ereignissen folgenden die Befehle. Hierbei handelt es sich um die Auslöser einer Aktion, welche anschließend wiederum besagte Domänenevents zur Folge haben. Bis hierhin hätte man wahrscheinlich nicht mehr als eine andere Art von Aktivitätsdiagramm gezeichnet. Erst mit dem dritten Schritt entfaltet das Event Storming seine volle Wirkung. In diesem werden die Aggregationspunkte erarbeitet, deren Verantwortlichkeit die Übersetzung von Befehlen in Ereignisse darstellt und welche entweder Bezeichnungen konkreter Domänenobjekte oder externer Systeme tragen können. Jene werden dann noch erweitert um mögliche Benutzerschnittstellen und globale Richtlinien.
Damit liefert ein Event Stroming alle Bestandteile die notwendig sind, um eine passende Softwarearchitektur für die gestormten Abläufe zu erstellen. Diese kann zum Beispiel dadurch vorbereitet werden, dass man den zeitlichen Ablauf des Stormings aufgibt und alle Befehle sowie Ereignisse den jeweiligen Aggregaten zuordnet. Dadurch ergibt sich eine Komponenten- bzw. Systemübersicht. Insofern die Chance genutzt wird und die Fachbegriffe während des Workshops entsprechend dokumentiert werden, ergibt sich darüber hinaus auch fast automatisch ein Glossar.
Obwohl also die Ergebnisse eines Event Stormings selbst schon eine Art von Prozessdokumentation darstellen, so sind sie doch langfristig nicht dafür geeignet. Ihr tatsächlicher Mehrwert besteht viel mehr im Austausch der teilnehmenden Stakeholder, sowie der sehr detaillierten Beschreibungen aller Aktivitäten, Objekte und letztendlich der betrachteten Domäne. Die tatsächliche Dokumentation sollte anschließend eher in Form bekannter Diagrammtypen erfolgen, wie sie bspw. von der UML bekannt sind. Dazu zählen vor allem die Aktivitäts- und Komponentendiagramme, welche selbstverständlich noch durch einige erklärende Worte zu ergänzen sind.
Die Besonderheit eines Event Stormings und somit auch seiner Endergebnisse wird noch deutlicher, wenn man bedenkt, dass für Workshops dieser Art üblicherweise große Räume und eine Unzahl an farbkodierten Sticky Notes genutzt werden. Dies fördert die Interaktion zwischen den Teilnehmenden weitaus stärker, als es Remote Tools wie zum Beispiel Microsofts Whiteboard oder das Miro Board könnten. Es hat aber den großen Nachteil, dass die so erzeugten Ergebnisse durchaus eine gewisse Fragilität aufweisen und sich im Grunde nur über ein Fotoprotokoll ohne größeren Aufwand digitalisieren lassen. Daher mögen manche Event-Storming-Experten über die digitalen Lösungen zwar ein wenig die Nase rümpfen, mit ihrer geringen Eintrittshürde und der besseren Persistierung der Ergebnisse weisen digitale Werkzeuge aber auch Vorteile auf, die man nicht unterschlagen sollte.
Wann Event Storming gut geeignet ist:
- Wissensaustausch zwischen unterschiedlichen Experten und/oder Stakeholdern
- Beschreibung von bestehenden Strukturen oder Abläufen, die geändert werden sollen
- Identifikation und Dokumentation von komplexen Abläufen
Wann Event Storming weniger gut geeignet ist:
- Wenn nicht genug Zeit besteht, um mit den wichtigsten Experten und/oder Stakeholdern einen Workshop durchzuführen, der mindestens zwei bis vier Stunden umfasst
- Wenn kein oder nur wenig Wissen bezüglich der zu diskutierenden Strukturen und ihren Anforderungen bestehen
- Wenn es sich um Designaufgaben handelt, die in sich schon so simpel sind, dass sie den Gesamtaufwand nicht rechtfertigen
- Wenn große Teile der Teilnehmerschaft nur sehr wenig technisches Grundverständnis besitzt
Dieser Beitrag wurde verfasst von:
