EventStorming – From Big Picture to Software Design

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.

What is a Domain Event?

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:

Be written using a verb at the past tense, preferably using the passive form
Be relevant for domain experts

Examples of Domain Events could be:

Item added to cart for a domain like e-commerce
Account debited for a domain like banking
Claim rejected for a domain like insurance
Ticket sold for a domain like online ticket sales
Room booked for a domain like hotel reservation

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.

Why a timeline?

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.

Different levels of abstraction

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:

Big picture: At this level, you can explore a whole business line, crossing corporate silos boundaries by gathering in the same room people with different backgrounds and who each possess one part of the truth.
Process modeling: At this level, you model a single business process, from its beginning to its end, making sure you don't leave any room for ambiguity and clarify all the business rules.
Software design: At this level, you start designing your software, using building blocks from Domain-Driven Design and a reactive programming paradigm, each sticky note potentially turning into a software artifact during the implementation phase.

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.

Where does it come from?

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.

Software Design EventStorming in a nutshell

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.

Why does it work?

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:

Simplicity: Its incremental notation and its low-fi aspect make EventStorming very simple to explain and allow to jump in the modeling phase quickly, without a cumbersome notation.
Visual: With EventStorming, you make the implicit explicit by visualizing things as a whole, keeping everything in front of your eyes.
Collaborative: No domain expert, as good as he can be, can cope with the cognitive load of a complex domain. Only by collaborating can we achieve a complete understanding of the overall problem.
Engagement: Because the workshop is done standing in front of the large modeling surface and because everyone gets a deck of sticky notes and a marker, everyone feels connected to the subject matter and has the opportunity to participate.
Transcendence of communication silos: By inviting people with a different point of view and background to participate, we overcome organizational dysfunctions by allowing people to efficiently share their domain knowledge and solve problems together.

Why should I care?

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.