Improve Your Business Processes with Event Storming
Earlier learning about business systems meant mapping the business processes through technical modelling approaches or using trial and error to write the code as you build a solution. Due to the technical nature of these models, many domain experts are left out of the conversation. Developers are not the only people thinking about software development, your company’s business team, your customers are also thinking about software development. To transform domain knowledge into business software use Event Storming.
What is Event Storming?
Event Storming is created by Alberto Brandolini, and it is a workshop for exploring business domains. Event Storming includes multiple levels of stakeholders in the business and drives greater understanding and productivity by simplifying the approach. It is a visual and interactive process that encourages team members to collaborate and share their knowledge to uncover domain events and identify business rules.
Event storming can be used in different scenarios:
- To discover the most effective areas for improvements in your business.
- To explore the viability of a new startup business model;
- To envision new services, that maximise positive outcomes to every party involved;
- To design clean and maintainable Event-Driven software, to support rapidly evolving businesses.
Let’s look at Event Storming Concepts
- Events (orange): These represent the domain events and anything that is relevant to a domain expert. They are written in past tense and provide the underlying details that feed into the later categorization steps.
- Commands (blue): These are requests to do something. They can originate from a user or system or by another event.
- System (pink): These represent systems involved in the domain. They may issue commands or receive commands along with triggering events.
- User (yellow): These are human users involved in the process. They may be a single person or a department/team.
- Aggregate (tan): This is the first level of categorization and can be thought of as the “thing” that a group of events operate on.
- Data (green): This represents data that may be critical for a user or system to make a decision.
- Policy (grey): These represent standards or rules that may need to be executed, such as rules for a compliance policy.
How the Event Storming Process Really Works
Step # 1 – Event discovery
This is the first phase of event storming. We treat this phase more of brainstorming rather than any analysis.
- We break down a scenario or a business process into a series of domain events.
- We write a short description of each event on a sticky note
- We place all the event sticky notes in sequence on a timeline
TODO add a diagram
The events must be worded in a way that is meaningful to the domain experts and business stakeholder.
Step #2 – Connect domain events to commands
After identifying domain events, we begin to evaluate each event for its causes and consequences and identify what triggered this event (e.g., users, other events, or external systems). The trigger or cause of the event is noted as a command. Commands are traditionally documented on blue sticky notes in the present tense and often represent user interactions with the system (e.g., “Submit a purchase order”). However, we may want to document commands as both user and system actions.
By combining Events and Commands, we will be able to map the business rules of a domain. Once mapped out, they provide a very good understanding of the processes necessary for implementing a consistent software system.
Step #3 – Describe the data
To truly define a command, we need to understand the data that is needed for the command to produce the event. For each command and event pair, we add a data description of the expected attributes and data elements that are needed to make such a decision.
In this step, we also fully describe the policies or reactions following an event. Reactions are the necessary actions or results following an event and are noted in the present tense. For example, an event-reaction process flow might state, “When a new account is created, we will send a confirmation email.”
Example diagram
For high-level event storming, the process can end once your team has added domain events, commands, and reactions. However, event storming can be combined with the technique of domain-driven design to define the structure of your system and start your team on the implementation.
Define the business context
We can start grouping together modules with an element called bounded contexts and label them. We can then connect these bounded contexts with arrows to show how the modules within a bounded context interact with other contexts. For example, we have grouped together commands, reactions, and events that deal with bookings and orders. The bookings and orders context is linked to the payment context, because once a booking is approved, the system needs to fire a command asking a buyer to make a payment.
To Conclude
Learning about the system by writing code is a very expensive way of understanding business processes, instead use event storming which includes multiple levels of stakeholders in the business and drives greater understanding and productivity by simplifying the approach.