My last Event Storming blog was like a stew I made by throwing in everything from the fridge and pantry. Maybe the stew was okay, but most of the individual ingredients got lost in the mix.
This time, I’m including the specific points to back my position as to why you should start using Event Storming now. Although, in my opinion, choosing Event Storming doesn’t take a lot of convincing to make it sound more appealing than other techniques.
So, why should Event Storming be used in place of other more established domain modeling processes?
While it isn’t beneficial to always try out the latest and greatest whiz-bang gadgets, not keeping tabs on emerging and promising trends can prevent your team from becoming more efficient.
Event Storming is one of those trends businesses need to start looking in to. ThoughtWorks bumped up Event Storming from ‘Trial’ to ‘Adopt’ status on their November 2018 Technology Radar. This endorsement should give credibility to the rise of Event Storming.
Event Storming is a lean and efficient modeling process to rapidly gain group understanding of complex business domains across business disciplines. It was formalized by Alberto Brandolini by mashing up several different techniques into one. The goal was to create a modeling process that is more fun than existing processes while using the creativity of all the participants so that group learning can be maximized.
The following points back up this claim.
Fits Many Use-Cases
Because Event Storming is based on a simple strategy, it increases the applications Event Storming can be applied to. The flexibility gained from a simple strategy allows the skill to be applied throughout the development process or even outside the development process. Event Storming can be used to understand complex business as well as develop ideas.
Use Event Storming for:
- Understanding greenfield applications
- Understanding brownfield applications
- Verifying new business process ideas
- Assisting to uncover bloat or inefficiencies in processes
- Understanding complex ideas or processes
Lean and Efficient
A key tenet of Event Storming is to keep the meetings lean and efficient by only inviting those who can ask questions and those who can answer the questions. Invite the developers to ask the questions and the domain experts to provide the answers. I know this is easier said than done, but don’t invite people who don’t/can’t contribute. Nothing derails a meeting more than a bunch of unneeded people that have their own agenda.
Meetings are also efficient due to the gamification of Domain Driven Design (DDD). Using gamification encourages participants to collaborate with each other using low-tech tools. If you have some colored stickies, some markers, and a wall, you have all the tools needed to Event Storm. Unlike heavy modeling techniques which require hours to develop a basic understanding, Event Storming is light which allows the team to be up and modeling in under an hour.
Rapidly understanding the domain or complexity is the goal.
Business Process Perspective
The ability of Event Storming to keep the dialog on the perspective of the domain being investigated rather than on the perspective of the User makes Event Storming more effective than other modeling techniques.
User Story Mapping, similar to other methodologies, focuses on discussions based on how the user interacts with the system. Using the user perspective to define the system works well when creating User Stories, but the mapping doesn’t provide as much clarity about the business process across time.
Event Storming keeps the focus on the business perspective by starting with modeling the events that affect the domain. After most of the events are known, then the participants can proceed to determine the commands or event triggers that are modeled along with the source of the command. The sources can be users, external systems, or time.
The UI is not totally left out of the model though. If the user needs to see some information to make a decision, then a Read Model stickie can be added to represent that information.
BYO Development Methodologies
Bring Your Own Development Methodology. I’ve only used Event Storming with Scrum but I don’t see why you can’t use it with most development methodologies.
Although Event Storming doesn’t really offer any opinions to what development methodologies can be used, I will say Event Storming meshes up nicely with Scrum.
Once the Event Storming model is completed, Themes and Epics can easily be based upon each Source-Command-Event stickie stack.
One reason Event Storming meshes so well with Agile environments is due to the overlapping principles. Similar to Agile, Event Storming encourages individuals and interactions over process and tools. During modeling, participants are standing directly face to face using stickies instead of everyone sitting around a table with their heads down in a requirements document.
Event Storming also encourages the production of working models over comprehensive documentation. It is important not to get bogged down on small details or try to solve a disagreement on the same event for more than several minutes (the amount of time is subjective).
If the Event Storming facilitator feels like productivity has stalled, then the facilitator should mark the unresolved event with a red stickie as a future discussion placeholder and have the participants move on. The event timeline won’t be completely solved during the first iteration. The event timeline should only contain important domain events so the model doesn’t become over-documented and cluttered with distracting events.
Good Starting Point
When tackling something unknown or complex, have you ever asked the question “Where do I start?”
Event Storming provides an excellent starting point for generating models or starting other processes. The big win with Event Storming is when domain experts and developers are on the same page for domain knowledge and domain language.
Having this foundation will greatly improve the chances for a successful implementation. Developers can begin the next fun step of figuring out what technologies and architectures will be needed to implement the process. Microservices? Yep. Event Sourcing? Go for it. Monoliths? Of course. Blockchain? Probably. 🙂
To succinctly rehash all this, we can all agree that there is incredible value in quickly getting domain experts and developers speaking the same language and having the same knowledge, to verify a process, or to decompose a complex problem.
Event Storming provides that lightweight framework to accomplish this in a lean and efficient manner. Once you use Event Storming, you’ll find out that it is a technique that can be applied in many more scenarios. It is a tool you can keep using over and over again.