EventStorming

Introduced in 2013 by Alberto Brandolini and inherited from DDD (Domain-Driven Design), EventStorming is a collaborative software design workshop that aims to break down the silos between an organization’s departments and help people converge toward a common understanding of business processes. EventStorming can assist you in exposing any organization or system inconsistencies and help people identify areas for improvement.

Describing business processes visually while seeking a consensus between participants feeds decision-making within the organization. By making it possible to understand all the system components, EventStorming helps the actors make wise decisions, possibly structuring and decisive, in an informed way.

EventStorming generally begins with describing the events occurring inside a given domain, modeling the possible interactions between this domain and external systems, and then identifying friction points and risks. After that, you should define more precisely the actions (or commands) that can trigger these events and the actors concerned by the related decision (personas).

Then, you should describe the policies that characterize the business logic. It encompasses the processing blocks triggered by a command and producing events and the cause and effect logic between the events themselves. The other important objective of EventStorming is to learn about domain concepts or objects and create a language shared with domain experts.

To finish, the workshop can go as far as designing the interface by drafting the views (read models) necessary to inform the decision-making of the actor concerned, the views possibly being screens, documents, or reports.

There are several EventStorming depending on the desired purpose:

• Big Picture EventStorming is ideal for launching a project;
• Design Level EventStorming gives inputs about how the system must be implemented;
• Value-Driven EventStorming is a way to map out the value chain based on the storytelling of events;
• UX-Driven EventStorming focuses on the user journey to provide an optimal experience;
• EventStorming as a retrospective workshop uses the chain of events as a way to seek opportunities;
• EventStorming as a learning tool helps new team members better understand the system in which they will be involved.

The group of participants’ composition depends on the workshop’s purpose. For example, a Big Picture EventStorming typically involves a domain expert, a representative from the development team, and possibly an architect. In contrast, a Design Level EventStorming does not necessarily involve a domain expert.

EventStorming uses a precise color code. As the representation of the system can quickly become relatively complex and extensive, it is strongly recommended to respect this code. This will help you keep the artifact intelligible:

• The orange stickies are used for events related to the domain. These events represent a state change occurring on a domain object. They must be named using the name of a business object followed by a past participle verb.
• Light yellow rectangular (or square) stickies can be used to identify domain concepts or objects. They are useful for visualizing the process better.
• To identify problems and opportunities along the chain of events, two colors are used:
  • Dark green stickies highlight possible opportunities;
  • Dark purple stickies indicate possible friction points or identified risks. The most sensitive problems, i.e., those that must be treated as a priority, are distinguished by turning the sticky 90°, which forms a diamond.
• The pink rectangular (or square) stickies represent the external systems involved in triggering certain events.
• Blue stickies describe users’ actions (or commands) on the system. They are generally associated with a dark yellow stickie which specifies the persona concerned by the command.
• The light green stickies represent the views that must be provided to the user to help them decide on the command. You can associate wireframing drafts with them. A view can also be a document or report produced by the system. More generally, it is a presentation of the state of the business model to the user or the other system involved.
• The lilac rectangular (or square) stickies are used to describe any rules (policies) causing an event to occur or caused by the occurrence of an event.

The expected artifact is a physical or digital wall on which the stickies are placed, organized by groups representing different event sequences or processes.

Step 1: The first step of the workshop is to define the different events that make up the system (orange sticky notes) and sort them in chronological order.

Step 2: Then, you should identify the possible problems (purple sticky notes) and opportunities (green sticky notes) that may arise at each stage of the process. This step is essential because it influences which parts of the system you will focus on next.

Step 3: You can now describe the system in more detail by identifying personas (yellow sticky notes), commands (blue sticky notes), and external systems (pink rectangular sticky notes).

Step 4: You should then describe the rules (lilac rectangular sticky notes) that can condition the occurrence of certain events and the information (green sticky notes) that must be provided to users to help them decide.

Step 5: To make the process easier to understand, you can aggregate several events around a domain or a business concept (light yellow rectangular sticky notes).

Olivier von Dach is an expert in Software Craftmanship and has extensive experience in leading EventStorming workshops. Here he shares some recommendations to help you get the most out of this workshop:

• Use a digital wall to run the EventStorming workshop remotely. In this case, it is more convenient to start from a template that contains an explanatory legend of the different types of sticky notes;
• Allow some tolerance in formulating events and commands, at least at the beginning. It will prevent participants from being intimidated when they drop sticky notes;
• After some sticky notes are placed on the wall, ask questions to participants to understand their intentions and make corrections when necessary;
• Keep a short name for sticky notes. The sticky notes’ explicit typology (i.e., the color code), their layout, and their sequencing according to each other should be enough to make the artifact understandable without ambiguity;
• Split the whole workshop into one-hour sessions to keep the participants’ energy high. This first session is generally used for discovering the workshop and/or the domain;
• During a session, ask a participant to describe a business process every twenty minutes.

EventStorming is a good way of starting a project. Then, you can follow up with more tactical sessions, for example, Example Mapping sessions to perform specification by example and, in particular, specify the rules associated with policies.