The first association brought to mind by the term “Event Storming” is a well-known method of generating ideas in a group, i.e. “brainstorming”. Although you can find several features common to both terms (group meeting, creative nature of activities), the difference lies in their purpose and use.
First and foremost, Event Storming is a tool for gaining knowledge and understanding the essence of a given business. It is particularly helpful when there is a need to understand an innovative or unusual domain that does not fit into standard business archetypes.
To answer this question, we will use a practical example of improving the work of a “coffee cooperative” associating coffee lovers working in one of the branches of our company. It’s domain includes shopping, monitoring and handling consumption of raw materials (coffee, milk, sugar), registration of people, orders and subscriptions for coffee preparation (standing orders with specified parameters including absence of subscribers), maintenance and repair of equipment, cost allocation and individual settlements of members of the cooperative (payments and withdrawals). Colleagues who asked us for help (Client) expressed their desire to do away with manual paperwork and abandon tedious calculations in Excel sheets in favor of dedicated software automating these activities. Instead of traditional business analysis (e.g. conducting extended interviews with various business representatives or monitoring their daily work) we proposed the organization of Event Storming workshops.
We invited Client’s domain experts, analysts, developers and moderators. Open space devoid of tables and chairs, a view of rows of colorful sticky notes and a long paper roll on the wall encouraged people to work together.
We started by getting familiar with the general characteristics of business activities of the cooperative, then we asked our experts to write down all the important facts from their field on orange sticky notes and to put them in chronological order. In accordance with good practices of Event Storming, we wrote down the events in past tense, e.g. “Subscription added”, “Package sent”. It facilitates the process of recalling specific, significant events regarding the business process.
Gathering crucial experts and analysts in one place and time has created an opportunity to harmonize the meanings of concepts used and the course of business process so that everyone understands them in the same way. The work of experts was accompanied by numerous questions of developers and analysts, as a result of which all participants interpreted the language and concepts used by the Client in the same way. With this approach, at the very start of the design process, we introduced the so called ubiquitous language. The meeting moderators ensured that the transferred knowledge was consistent and complete, helping domain experts to focus attention on the order of events, real examples and circumstances of events. As a result of the first session of the workshop, a set of chronologically organized domain events was created.
After a break, we asked our domain experts to match proper activities and people to the set of events on the wall. This is how a set of potential actors (i.e. individuals performing various activities in this process) and activities (system commands) has been created. The next notes used by experts to complete the model concerned information required to perform the activity and crucial business rules on which the course of business events depends.
The final stage of the work consisted in grouping the events and gathering them around groups of data (aggregates), the processing of which cannot be separated in time (transaction boundaries). This allowed us to get structured information about the domain and the system that form a good and understandable by everyone basis for creating a project model in accordance with Domain Driven Design. In the next step, the effects of work were detailed using the User Story Mapping and User Journey techniques, resulting in material for designing a modern architectural solution.
“I especially like the dynamics and mobilization of the participants,” summarizes Paweł, Client’s domain expert. “I think that this form allows to effectively transfer knowledge, and thanks to the lively discussion, it helps to maintain high concentration level for longer,” he adds.
Kamil, an architect present at the workshop, said: “A well done Event Storming has a good chance to end at the level that allows starting the creation of prototype.” Thanks to this, it is possible to start working on the domain model and implementation without detailed documentation of all the rules. As a result, it is possible to quickly present a working example to the client and obtain valuable feedback. “In this way, we implement Agile principles better.”
Robert, our developer, was also very enthusiastic about the method: “Event Storming allows you to quickly recognize and understand the domain. It naturally supports DDD, allows decomposing the domain by conducting the process of analysis / modeling starting with vision, through subsequent stages of detailing, ending with tactical patterns that are represented in the code. It supports designing event-driven and loosely-coupled architectures, in particular the microservice architecture. It also supports the creation of evolutionary architecture. It uses a language that is understandable by everyone and with the use of informal notation allows anyone to be added to the discussion and include everything in the model.”
According to Artur, an experienced system analyst, “Event Storming facilitates, or even forces establishing a common understanding of concepts and operations as well as their meaning by business, analysts and developers, quick discovery of inconsistencies, duplicates and lack of knowledge / open issues. Using sticky notes visualizes operations on requirements (parking, deleting, linking). This form requires extensive involvement of all participants and allows to easily detect lack of it.”
Event Storming is a lightweight method that does not require a lot of time and resources, thanks to which we can build a coherent, commonly understood and accepted image of the business domain. Such approach minimizes later issues resulting from misunderstanding between people involved in the IT project and saves a lot of resources and time at later stages of delivering the solution. Unequivocally positive experiences and flattering opinions regarding Event Storming from a large group of IT professionals are the best recommendation for using this method in the software development process.
Author: Hubert Jakubiec, Analyst in Altkom Software & Consulting