Developing a comprehensive understanding of business systems is hard work. It usually involves high-level modeling or complex process mapping. This can be a highly technical and laborious process that involves a lot of trial and error. Creating BPMN diagrams or UML schematics can be very useful in understanding the broader functioning of a business, but they are fundamentally technical in nature and can exclude non-technical domain experts.
Domain-Driven Design
Domain-Driven Design is a methodology that establishes a technology-independent language that allows for a detailed understanding of business needs and processes. This allows stakeholders to communicate their domain knowledge to the rest of the team in a language-agnostic manner to develop a shared understanding of systems.
What is Event Storming?
Event storming is a workshop-based approach to Domain Driven Design that brings technical and non-technical stakeholders together to explore complex business domains. It focuses on domain events that are generated in the context of a business process or business application. It usually involves product owners, domain experts and developers.
The event storming method was introduced and publicized by Alberto Brandolini in Introducing EventStorming. It is used as a technique to rapidly capture a solution design and improve the team’s understanding of the design.
Event storming is a form of group learning and is a fun way to integrate development and product teams to create alternative solutions together. Event storming may also be useful for teams with mature products to order the process and find out about bottlenecks and areas of conflict.
An event storming session is usually conducted to:
- Create a business model for the development of a project.
- Gain a “big picture” awareness of the product model in all its complexity, highlighting its goals and needs.
- Visualize the product model and brainstorm alternative solutions.
- Find bottlenecks and areas of conflict on mature products.
The Benefits of Event Storming
While building a product it is important for the development team to be well-versed in the business domain the product operates in. It allows for a clearer initial analysis and a more focused build. A workshop like an event storming session can boost the overall co-operation between business and product teams.
Quick: Most other business process modeling techniques are an in-depth deep dive into the operations of the business. They involve using complex data models and can take weeks to depict an accurate picture. Event storming is a rapid approach to modeling domain-driven design. An event storm is usually a single-day event where a complete business process can be mapped in a few hours.
Shared Understanding Between Technical and Non-Technical Stakeholders: Unlike UML, an event storm creates a representation of a business process that can be easily understood without any prior technical knowledge.
Collaborative: The core concept of an event storm is to encourage participation and interaction between domain experts. It creates an engaging environment to create business models and results in the discovery of more valuable insights.
Effective: The greatest benefit of event storming is the conversations it starts. Teams can use the knowledge gained in the workshop to inform future modeling processes and build products, or can simply use event storming to better understand business processes and make better decisions going forward.
Conducting the Event Storm
To conduct an event storm you need to gather various stakeholders with specific domain expertise together. This can be done in a physical location or virtually using a collaborative whiteboard tool like Creately. It allows you to conduct the entire session remotely on a single, infinite canvas and can be used as a shared space where stakeholders can exchange thoughts and ideas in real-time.
Step 1: Domain Events
The first step is to identify domain events. They are factual statements about the things that happened in a business system. Participants brainstorm and list down all the things that happened in a system that triggered important reactions. Then they list down these events as colour-coded notes on the virtual canvas. It is important to phrase these statements in the past tense so participants can frame this as a ‘what happened’ statement. As participants add events to the canvas, you can begin to organize them according to the time frame in which they occurred.
Step 2- Commands
The next step is to identify why the event occurred. In this stage, the team analyzes what triggered the events. While events are factual statements about the past, commands express our intent for something to happen in the future. Commands are usually listed down on blue notes. While events are captured as past tense statements, commands are listed down as present tense intentions. Commands may be documented as both user and system actions.
Step 3- Aggregates
These are the things that happen in a system that generally take place in a group of events. They are higher-order business entities that should be represented as nouns.
For example, ‘Order Process’. An aggregate usually consists of a collection of notes on the canvas.
It is represented by a cluster of events with corresponding commands and the responsible actor. That aggregate can then be named and placed on a larger color-coordinated note on the canvas.
Step 4 – Bounded Contexts
This is a high-level structure that consists of categorizations of functionality that group related entities together. The team begins to group together modules within an element called bounded contexts by drawing a box or circle around the related modules. You can then begin context mapping by illustrating how modules within a bounded context interact with other contexts. Simply put, all related events would fall into the same bounded context. For example, all events related to shopping carts would fall into the shopping cart bounded context.
Tips for Conducting Your Event Storming Session
- Participants: The key aspect of a successful event storm is organizing the right people. Participants should consist of key stakeholders with domain expertise across multiple domains. An effective event storm usually has a small group of stakeholders to ensure free-flowing conversation and a collaborative environment.
- Plan Sessions: Set goals and intentions for the session. This allows you to be more focused on what should be involved in the session and what aspects should be left out.
- Send Instructions Ahead of Time: Allow participants to understand what the point of the exercise is and what is expected of them. Send instructions of what the key is and what different colored notes represent, so participants have a clear understanding while conducting the session
- Have Discussions in Nontechnical Language: Ensure conversations are not bogged down by the specifics of implementation. These conversations should be more conceptual in nature so that everyone can participate, regardless of their technical background.
- Provide Examples: It is helpful to showcase a completed event storming canvas so participants know what they need to work up to.
Have Experience Conducting an Event Storming Session? Tell us About it.
Have you participated or conducted an event storming session before, we would love to hear about your experience and some of the learning you came away with. Let us know your thoughts in the comments section.