EventStorming

What is 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.

The different uses of EventStorming

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.

What are the components of an EventStorming?

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.

Color coding summary from Alberto Brandolini's Introducing EventStorming ebook

How to run an EventStorming workshop

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).