Wie genau entwickelt man Software oder ermittelt Anforderungen, wenn das Verständnis der jeweiligen Domäne im Team noch nicht entwickelt ist? Jede Software soll ja die Probleme aus einer spezifischen Domäne lösen und die fachlichen Prozesse unterstützen oder ermöglichen.
Eine Domäne kann laut Eric Evans wie folgt definiert werden: „A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software.“
Sie ist also ein abgegrenzter Fachbereich von Wissen, Einfluss oder Aktivität und ergibt sich bspw. aus dem entsprechenden Unternehmen, das diese Software einsetzen soll, dessen Branche und zu lösendes Problemfeld – z.B. eine Finanz-Domäne (z.B. für eine Banking- oder Crypto-Software) oder Telekommunikationsdomäne (z. B. für eine Vertriebspartnersoftware). Selbstverständlich kann und wird diese meist aus weiteren Sub-Domänen bestehen, je nach Komplexität der Domäne und Software. Die Modellierung von Domänen & Co. ist aber eher ein Teil der Methode „Domain Driven Design“.
Die entsprechenden Fachexperten haben naturmäßig meist ein tiefes Wissen der Domäne, doch letztendlich müssen auch die Umsetzer der Software die Domäne verstehen, wie bspw. Die Entwickler, Designer oder Product Owner. Wie will ein Team eine Software umsetzen, ohne die Domäne dahinter zu verstehen? Dieses Team ist schließlich für die Lösung der Probleme zuständig. Nur mit einem tiefen Verständnis können auch die passenden Lösungen entwickelt werden.
Event Storming ist eine praktische Methode, um auch bei den weiteren Team-Mitgliedern ein Grundverständnis der Domäne zu schaffen und die Sprache bzw. Begriffe dieser Domäne zu verstehen. Stellen Sie sich vor, Sie müssen eine Software in der Energiebranche entwickeln und werden mit Begriffen wie Marktkommunikation, Netzbetreiber und EDIFACT bombardiert. Ohne ein Grundverständnis wird es hier kaum möglich sein, gute Lösungen zu entwickeln. Deswegen wird beim Event Storming in interaktiven Workshops mit vielen Haftnotizen und den Fach- und IT-Experten die Domäne soweit erforscht und ein interdisziplinäres Verständnis aufgebaut, dass man mit der weiteren Systemmodellierung und -umsetzung fortfahren kann.
Wie der Name der Methode schon sagt, wird hier basierend auf fachlichen Ereignissen gearbeitet, die während des zu betrachtenden Geschäftsprozesses passieren. Diese Ereignisse werden in der Vergangenheitsform beschrieben, es sind also Ereignisse, die bereits passiert sind.
Neben den Ereignissen, die konventionsgemäß in orangefarbigen Haftnotizen aufgeschrieben werden, gibt es u.a. auch folgende Haftnotizen:
- Blaue Haftnotizen: Befehle (“Commands“), die zu einem bestimmten Ereignis führen (z.B. „Vertragsbestätigung senden“, „Account erstellen“, „Produkt kaufen“, …)
- Gelbe Haftnotizen: Akteure, die den Befehl auslösen (z.B. End- nutzer, Kunde, …)
- Violette Haftnotizen: Geschäftsprozesse, die einen Befehl mit einer bestimmten Geschäftslogik verarbeiten und die dadurch ein oder mehrere Ereignisse erzeugen (z.B. „Rückläufer bearbeiten“, …)
- Pinke Haftnotizen: Externe Systeme, die einen Befehl auflösen können (z.B. CRM-System, CMS, …)
- Rote Haftnotizen: Fragen, Probleme, Risiken oder Entscheidungen
- Weitere gelbe Haftnotizen: Sogenannte Aggregate, die mehrere Haftnotizen wie Ereignis, Akteur und Befehl gruppiert und einen Namen gibt
Es gibt noch weitere Haftnotizen, die etwas technischer sind. In der angeführten Literatur können Sie mehr über diese Möglichkeiten erfahren.
