EventStorming is a workshop format invented by Alberto Brandolini, that enables massive learning on complex business domains and promotes collaboration between different disciplines and across teams. EventStorming is a discovery and modeling tool, that involves a group of people collaborating in front of a large modeling surface using colored sticky notes and markers.
It simply starts by organizing Domain Events on a timeline.
A Domain Event is represented by an orange sticky note where you simply write down something that happens in the process you want to model.
The most important things to know about a Domain Event is that it should always:
Examples of Domain Events could be:
These are very naive examples, but actual real-life domain events can become very powerful in terms of clarifying the semantics of the domain.
Writing an event as something that has happened helps participants focus on what is meaningful to the domain. If you cannot formalize something that you think important with a verb at the past tense, it might just mean that you are not expressing the right idea. Past tense helps to be more precise, concise and domain-specific. Using sticky notes to write down events using this format lowers the entry bar in the domain and allow everyone to participate.
Conversely, if something that is written down does not make any sense to a domain expert, is it really a Domain Event? Domain experts are the ultimate judges when it comes to the language used in the domain, and even though we don't want to be too pedantic at first, using the right words is important in order to build a Ubiquitous Language shared by everyone.
What you more than often end up with is actually two or more domain experts from different departments and with different backgrounds who disagree on the semantics of a given word being used. This is typically a sign of some ambiguity in the domain that needs to be explicitly clarified. EventStorming will put this kind of ambiguity in evidence and provide an opportunity for people to talk it through.
For years, we have been taught to design software in a structural way, thinking in entities and relations, mostly because of the predominance of relational databases in the software industry. This worked well as long as we did not need to scale either in terms of complexity or availability.
But when we think about the business problems most companies face today, they are much more dynamic and complex, and structural modeling is simply not enough anymore. We need to understand the behaviors, not only the data. Therefore, EventStorming emphasizes temporal modeling instead of structural modeling. To fully understand modern-world business processes, we need this richer way to model domain complexity. It's less about the structure of data than it is about the flow of information.
Organizing Domain Events on a timeline makes it very easy for people to reflect upon the domain, focusing on what is really important, without having to learn any technical and potentially complicated notation. This kind of visualization also makes it very easy to collaborate with other people. By enforcing the timeline, we can see different business narratives forming and use the power of storytelling to make sense of that complexity.
Another strength of EventStorming is that it is very versatile. It doesn't matter which kind of domain you want to explore or how complex it is, the tool will not get in your way. On the contrary, it will help you gain clarity about the domain, in an iterative and incremental way, adapting to your level of maturity and domain knowledge.
Over the years, Alberto Brandolini and other members of the community have identified three main levels of abstraction for EventStorming:
Each level incrementally enriches the notation with new concepts, drilling down the problem space, getting closer to a concrete software implementation. Each new concept in the notation gets its own color and shape of sticky note, which makes it very easy to recognize on the modeling space.
At any given time, you can navigate up and down, going from exploration to modeling and then software implementation, and back up after one particular business process has been fully implemented or when you want to get back to an overview.
Alberto Brandolini is one of the most prominent advocates of Domain-Driven Design (DDD), an approach that addresses both strategic and tactical aspects of writing software to tackles complex domains in a simpler way. He is also an international speaker and has done many talks on the subject.
Even though EventStorming was born in the DDD community, it has surpassed its boundaries and can be used independently. This is especially true for Big Picture. Indeed, you don't need to be a DDD expert to run a Big Picture or event a Process Modeling EventStorming workshop. However, you will need strong facilitation skills if you want it to be efficient.
The closer you get to actual implementation, the more technical your EventStorming workshop will become. It's usually recommended to include mostly technical staff in the Software Design sessions unless you want to scare the business people away.
It is difficult to explain why EventStorming works so well until you have actually seen it in action.
Some of the reasons we can give however are the following:
In November 2018, EventStorming entered the Adopt circle in the Techniques quadrant of Thoughtworks technology radar.
In just a few years, EventStorming has become the de-facto standard, in the Domain-Driven Design community and beyond, to analyze complex domain, clarify domain boundaries, help identify your core domain, prioritize work, and move towards a microservices architecture.
Whether you are a software architect, a developer, a business analyst, a domain expert, a product owner, a UX designer, a tester, or any other role in your organization, you can leverage this simple but powerful tool to obtain better visibility and clarity on your domain.
In a few hours of workshop, you can tackle complexity and move from exploration to implementation, transcending communication silos in your organization.