“Merge the people. Split the software. It’s way simpler this way.”
Alberto Brandolini
Event Storming is a lightweight method aimed at collaboratively creating a model of a complex business flow. It is a workshop-based method invented by Alberto Brandolini to quickly find out what is happening in the domain of a software program. It has its roots in the DDD approach (domain-driven design), although you don’t need to know anything about DDD to use event storming with your team. The technique however isn’t only limited to software development. You can apply it to practically any technical or business domain, especially those that are large, complex, or both.
One of the simplest definitions of a domain states: “The Domain in software engineering is a sphere of knowledge.” It is a field of study that defines a set of common requirements, terminology and functionality for a software program constructed to solve any problem in a given field. In a non-technical environment, the domain could be any area that you’re trying to understand or improve. It is intended to support and accelerate the understanding process by bringing together relevant stakeholders to quickly model the broader business domain and its processes.
What do you need to facilitate an Event Storming workshop?
There are 3 simple rules for Event Storming to work:
1. The right people in the room: According to Brandolini, the right people are the ones who have questions to ask as well as the ones who would have answers to those questions. This group will likely be a mixture of stakeholders representing user experience, business, architecture, development and developers. Keep the maximum size around 6-8 people.
2. Unlimited modelling space: The goal is to get on paper (usually color-coded sticky notes) each significant event and process in one big map. To do this, you will need a large modeling space that allows your team to continue building on the process as questions and ideas arise without being limited in scope by the physical workspace. Traditionally, this approach has been applied with sticky notes on a big piece of white paper or wall and sharpies for writing. Prepare a room where tables and chairs are pushed aside (no sitting). We want lots of everything, because we don’t want to constrain the mental process.
3. Have a time limit: Two hours are recommended as the limit. Every open ended meeting might bloat. Keep it under control key people won’t be available for the whole day. Keep a visible agenda, or a timer. Just try to use participants’ time in the most effective way.
Goal:
The goal of the workshop is to better understand the business model and bring out dependencies, relations between behaviors, bottlenecks, etc. The workshop helps the team to understand the big picture of the solution by building a timeline of domain events as they occur during the business process life span. The focus in initial stages of the workshop is on identifying and sequencing the events that occur in the solution. The event timeline is a useful representation of the overall steps, communicating what must happen while remaining open to many possible implementation approaches.
“If you can’t describe what you are doing as a process, you don’t know what you’re doing.”
Edwards Deming.
Set the scene
Provide the group with a simple explanation of Event Storming. Explain enough so that people understand the concept of Events, Hotspots and External Systems. In its simplest form, an Event is just something that has happened in the past that matters. It could be a system, passing of time or the consequence of another event. Hotspots are used to park “problems.” We use this whenever we encounter a question we cannot answer, something that does not seem right or any problem we should look into.
I have found hotspots to be a very powerful tool when conversations go in circles or something is too complex to figure out in the session, just park it by creating a hotspot post-it note. External systems are systems that exists outside of the modeled domain that collaborates with the domain being modelled. Examples are Third Party systems or even Existing Systems.
Once you have explained these first three concepts, make sure that each person is equipped with their own post-it notes and a marker to write with. Have a legend up so people can quickly reference the colour stickie with the concept.
Domain events discovery
Together the group explores the business domain to unveil a comprehensive process. For training purposes, we asked the group to consider a very simple domain, an online Poke Bowl ordering system. We asked the team to organize events into a timeline from the starting event until the last event. In this step, everybody should write and post on the board all the Events that may take place in the system. We also asked group members to act this out by taking on the perspective of a persona in the domain, such as a “chef” to ensure that all views are considered. This is also the only phase when people may work independently and will create the basis for further exploration. People are quite often uncertain about whether they’ve identified a meaningful business event.
As a Facilitator it’s best to place the first event, it doesn’t have to be at the start. A 15-minute time limit is given for this session. Try to remain in the background and let the team discuss and figure out what needs to be done. They may disagree about whether something is an event, whether an event is in scope or not, whether or not two events are the same event, or whether one event should be two. They have to sort through these issues through conversation and discussion. Once the events on the wall are sorted out, someone is asked to tell a story from beginning to the end of the timeline. At this point participants realise how quickly they’ve created the skeleton of a system.
DDD Concepts and Event Storming
We then go through some more DDD concepts which are a bit more complicated. These include Commands, Actors, Read models and Policies. We provide some domain business rules around the system. Once again we shared a legend of what each concept it and the colour post-it to be used for that concept. The Command represents a decision made by a user in response to some information retrieved from the Read Model. The Actor is the person who issues the Command, and the System is the thing that receives the Command. Policies are Logic (business rules) that takes place after an Event occurs, and triggers other Commands.
Quite a lot introduced in this section so it’s important people do not get overwhelmed with the next pieces of the puzzle. It can be handy to go through another simple example if the audience needs something more relatable.
Get back to the flow
Now the team should prepare to add the new parts of the flow again. Get the group to come up with the Actors, Commands and Systems that the command is issued to. Time box this to 15 minutes again for the first pass. If the volume of events is quite large and the group is too, it can be useful for teams to take the events between the two Pivot Points and flesh them out. This can speed things up, and all will be replayed together afterwards so the shared understanding can still be achieved.
I try to steer groups away from being bogged down on whether the system is internal / external or how it should be named. It’s good to keep things fuzzy until absolutely necessary. For me, the primary thing with the System at this stage is just to identify that there is a thing which the Command has issued thus triggering the corresponding Event.
Understanding Aggregates
Next we explain Aggregates and Bounded Context. Bounded context is the setting in which a term appears, determining its meaning. Aggregates are a cluster of domain objects that can be treated as a single unit. Each context has a clear boundary and is consistent, having its own rules but still communicates with others. The group identifies aggregates that accept commands and accomplish events, and begins to group aggregates together into bounded contexts. Along the way, key test scenarios, users, and goals are identified and incorporated into the model. Finally, the relationships between bounded contexts are added to create a context map.
After spending some time on aggregates, we discuss ubiquitous language. All people involved in the product development should speak the language of the domain (workshop, requirements, code, etc.) to support a shared understanding. Based on that, we distinguish between areas in which a word has a different meaning from the business perspective. The participants are tasked to draw boundaries between the multiple consistent models that would coexist in our test domain.
In conclusion
KRS has found immense value in using Event Storming to brainstorm as a group. It is quick and light and provides value fast. Having the right people in the room and the ability for key information to be exchanged is priceless. It ensures everyone is included and can visualise the parts of the whole and have a shared understanding. You also get a quick view of what information is still blurry and can clarify misunderstandings early on. This helps in ensuring efficiency and not creating rework. The outcome is really in the knowledge shared, and not the paper trail.
Event Storming with KRS
KRS can assist with facilitating your first actual session. We guidenew users through the process in is a safe space that allows the best possible outcome. Learn more about our Event Storming expertise.
“The models are a byproduct of conversations, and it’s those conversations that are the real value.” Kevin Webber.
Additional Event Storming Resources:
- Alberto Brandolini’s original blog
- Aggregates as defined by Martin Fowler
- Blog explaining how event storming, DDD and reactive systems relate
- Alberto Brandolini’s Event Storming book
- Alberto Brandolini’s 50,000 Orange Stickies Later from Explore DDD 2017. Great overview of how the technique has evolved, tips for running a session, and articulation of the different types of sessions to run.
- An excellent example of Event Storming during a Red Hat Open Innovation lab “Using ‘Event Storming Practice’ @ Heritage Bank“
- A facilitators recipe for Event Storming