How does event storming help in understanding processes/systems better
What is Event storming?
Event storming is a collaborative approach of having all the stakeholders together and modelling the business “Domain” events. It can be the first step to “Domain driven Design” which can be applied for any domain say aviation, finance, retail, insurance and many more invented by Alberto Brandolini. Event storming is a tool to “Challenge the value” we deliver for end customers and here we don’t play with data or requirements but with “Domain events”.
When is it desired to use event storming?
- The first and foremost step we take when developing software for client partners is to “Identify the problem statement”. Many at times the project could be half the way through actual release, and there could be a lot of scope change requests making the process cumbersome. To avoid such situations, the event storming workshop could help us identify the right problem statement.
- To break knowledge silos in an organisation where people working in multiple streams addressing problems only within boundaries they work.
- When there are challenging domain problems and a question on where and how to start, event storming is the right technique to tie the knots.
How does event storming help in understanding processes/systems better?
Prerequisites:
- Have the right set of people in the room for the workshop
- Dedicated facilitators who have context on event storming technique is appreciable
- Have necessary markers, sticky notes and a sufficient space in the wall for collaboration. In remote setups, using online collaboration tools would be the ideal way to do an event storming workshop.
Interesting Fact:
One interesting fact about event storming is adding colours to the board elements. Here goes the colour palette and each colour signifies elements of event storming. Let’s see how colours can also add value to event storming!!!
Bringing in a scenario for better understanding of event storming,
“Considering an online food delivery application, that allows customers to place orders from restaurants based on delivery location. The ordered food is processed by the restaurant and delivered at door steps with the assistance of the delivery partner.”
The individual elements of event storming is explained with the scenario above. On combining the blocks of elements we get the entire flow of processes in a specific domain
1: Domain events
“Domain events” indicates the high level user flow mostly with the verb at past tense. Capture the domain events with inputs from all the stakeholders and there is no hard and fast rule that all the domain events should be listed at once. It can also be captured at the later part of the flow. Considering the scenario, the domain events would be,
2: User persona
There could be multiple user personas involved and there should be right trigger points of the personas. This is critical because user stories would be crafted based on the “User” persona we come up with.
Let me introduce you to the three personas in the event storming board,
**Refer to the dotted lines in board to know the “User” personas**
- Clara- The customer
- James- The restaurant admin
- Blossom- The delivery partner
Essentially, it’s not required to identify all the user personas at one go. As we flow through storming of events make sure to have an eye on which user is responsible for the flow of events.
3: Read Model
Read model represents something that the user persona visualises on the screen. It can be a design element or anything that conveys information for the user on looking at the screen. But it’s merely not data, but induces a decision made by the user.
Glimpsing into the read model 1 highlighted, Clara (the customer) chooses to select the delivery location based on which restaurants can be listed to order food. She gets to see <Home address> and <Office address>. Decision on the read model induces the “restaurants list” that comes up as soon as Clara chooses her delivery location.
4: Command
“Command” is usually what triggers the decision taken by the user persona. It’s basically an action performed by a user.
Getting into the “command” element 1 highlighted, that specifies the user’s action to select the delivery location. “Command” 1 paves way for the “Domain event” that the delivery location is selected.
Event Storming is a chain of blocks combined together. Where “command” 1 connects to the next “command” element 2.
“On selection of delivery location <command 1> the list of restaurants available for the delivery location are listed <command 2>”. The chain continues and goes far beyond.
Similarly, when Clara the customer has selected “The cart to review the order”, Clara should be able to perform four different actions which are highlighted in “Command” 5
- Select proceed to pay option
- Apply coupon code
- Update quantity
- Delete item
So, there can be multiple commands for a single “domain event”.
5: External System
“External systems” are used when interfaces from third party applications are interacting with the system. This element always gives a cautious view indicating the places where users interact with external systems
Zooming into the “External system” 1, when orders are placed successfully by Clara the user, the interaction of James the Restaurant admin pitches in. James tends to view the orders in a panel and confirm orders where an external ERP/OMS is used.
To give another example, in the “External system” 2, Blossom the deliver partner is able to track the way to reach Clara, the customer with the tracking integrations from the “Collect maps” Vendor
6: Policy
Policy is the middleman element between “Domain event” and a “Command”. It’s more of a logical condition which can most probably have a happy and a sad path. At times policy can also navigate to multiple actions.
“Policy” is connecting the dots between the “domain event” and the “Command”.
The common pattern observed in Event storming would be,
<Domain event> <Policy> <Command>
Into the example of Policy 1
<Delivery location is selected> <When the delivery location is selected> <List the restaurants available for the deliver location>
Into an example of Policy 3
Happy path: <Food items added to cart> <When food items are added to cart> <Select view cart option>
Sad path: <Food items added to cart> <When food items cannot be added to cart> <Show message currently unavailable>
7: Aggregate
Aggregate as the name suggests is the combining of several separate elements together. “Aggregate” element focuses on combining based on behaviour of the user and not on the data.
As you can see 1 & 2 highlighted here are “Aggregate” elements where Clara, the customer’s “Item selection” activities are grouped as one aggregate and her “Cart” activities are grouped as another
Glancing into “Aggregate” element 3 represents the “Payment” activities of Clara, the customer
“Aggregate” element 4 represents the “Admin panel order listing” for James, the restaurant admin
“Aggregate” element 5 represents the “Delivery payment support app” for Blossom, the delivery partner
8: Hotspots
“Hotspots” give a picture of blockers in the flow. But the general method to approach event storming is when the discussion in the group is prolonging and does not get in a way to solution something, then add a hotspot and move forward. The hotspots can later be discussed with domain experts or specific stakeholders and then arrive at a logical solution. Answers to the hotspots can also be business decisions that can be taken on a management level.
Referring to “Hotspot” 1, it’s just an alarming question of whether to have an OTP option for COD orders that can provide a means for fraud detection. But here it’s an unanswered question and we can also add a comment if required on who is the right candidate to provide an answer for the question. Remember “HOTSPOTS” are reminders for future discussions.
9: UI note
Though UI notes are not direct elements of event storming they are secondary but vital for clear understanding. The UI screens can be added or any comments on design perspective can also be added to the elements.
In the highlighted area, we see a question of whether to have a “pop up” to show “Not applicable message” indicates a design element that needs to be considered. It can be as simple as this or a description of a UI note can also be added.
10 : The entire board
Event Storming is the most collaborative and fun oriented way to gather information about the domain processes. For a domain there could be multiple streams and all of them are interconnected. A visual representation of such interconnection is “Event storming”.
How is event storming beneficial?
- The whole process is made visible for all the stakeholders at one shot.
- Event storming over documentation because reading the entire flow of processes in documents are tedious (preparing the documents as well)
- To identify the core problem and blockers quickly
- To break organisational silos as every move becomes visible to everyone
- Converting the event storming board to user stories becomes simple. For eg: “Aggregate” elements can be directly converted into high level epics
Tip:
When we start with event storming, we tend to move quite slowly. The initial few phases can take some time. But day by day we can reach maximum efficiency and the outcome from Event Storming is enormous and wholesome.
PC: Thanks to Mural for helping me draft the event storming board for the purpose of writing the article
Happy reading people!!!
Cheers :)
