Event Storming (apart from sounding like something Thor would do for his birthday) is a very efficient technique for solving one of the most difficult phases of starting up new projects – core domain discovery and documentation. It’s hard to argue that mistakes made at the early stage of understanding and mapping domain can have painful long-term consequences. In this article, I will try to explain how this problem can be tackled with a collaborative workshop format called Big Picture Event Storming.

By the end of reading this article you will learn:

How Event Storming is drastically speeding up modelling of the whole line of business systems
How domain model shaping can be achieved with some markers and coloured sticky notes
The importance of timeline in business process modelling
How event storming can help identify bottlenecks in processes
How to approach distributed online event storming
That DDD isn’t the only or even major use case for big picture event storming

What is it and who is it for?

Event storming, in a nutshell, is a collaborative workshop format, it is meant to help understand and map complex business domains. It is also meant to bring experts from various areas of your business together. Some of the good use cases for the event storming are:

Mapping of a new domain for a greenfield project
Analysis of your current domain model (perhaps in order to find some bottlenecks or ideas for improvements)
Analysis of existing value streams (they become apparent when you finish modelling)
Single complex process mapping (could be some key algorithm that your company depends on)
Remapping of legacy system domains (helpful if you are taking over or joining poorly documented systems)

While big picture event storming thrives in the modelling of complex systems, it is by no means limited to them.

Often in real life, we have to depend on a large group of people to get the cumulative business knowledge. The keyword here is “large”. It’s that amount of people that are often the cause of miscommunication. It’s what leads to mistakes and later, heavy costs of necessary amendments. I really like this quote from the father of big picture event storming (which by the way was first mentioned at around 2013 so it’s a fairly mature tool):

It’s developer’s (mis)understanding, not expert knowledge that gets released into production
Alberto Brandolini

This communication and transformation of the high-level design into implementation details is often a key problem in software development. Miscommunication may come in many forms and shapes. For example, some knowledge may have been lost because it wasn’t shared or documented enough before key people left the company. Regardless of the circumstances, I think a lot of us will agree, effective business communication can get challenging. Fortunately, like many other problems, this one has already been tackled by experts in many domains.

There are currently multiple ideas and ongoing debates focused on business design communication issues. To me, however, based on my experience, event storming works best and makes a lot of sense. If my word isn’t enough, perhaps the 23 thousand+ views on Alberto’s more recent

YouTube video on event storming does tell you a lot as well:

How does it work

There is a simple (base) recipe for a successful Big Picture Event Storming workshop. Obviously, the basic model can be adjusted or extended to your own needs but the core form should work well for most of us:

Invite the right people: You want domain experts, real domain experts with deep understanding and insight into their domains. It does not matter if it’s a management, analytics or a power user as long as they pose this deeper understanding of their environment.
Provide a large working surface: a large paper roll usually suffices. You can stick it on the wall
Describe a notation: some basic building block elements have to be defined. You can go with the recommended notation or anything else that you think would work best for your environment. Some of the basic elements are:
Aggregates (yellow stickers) – they group similar processes, commands and events
Commands (blue stickers) – simple actions, E.g. send email
Domain Events (orange stickers) – some significant domain actions usually in a form of a verb in past tense like “Order Purchased”
External System (purple stickers) – any third party components
Policy (pink stickers) – any kind of important logic or rules.
Read Models (green sticker) – any type of input necessary to make decisions
User (smaller, yellow) – any input provider
User Interface (white) – well… I think you get this one

This set of stickers combined with a large vertically extendable surface will allow you to model processes and sub-processes that shape the business. The surface will represent the axis of time going from left to right – past to the future. As they are added on the surface, sticky notes will spark conversations and discussion. For some people, this will be the first time they will see the big picture of what the modelled line of business is (it’s common to close yourself in a subdomain of larger business). This big picture moment, the moment of clarity may actually give birth to great new ideas for improvements in cross-department cooperation or perhaps show some inconsistencies or new opportunities. Companies may want to think about redoing this exercise on regular periods just to make sure everyone can still see the big picture and no opportunities for improvements are wasted.

How do I get started?

To begin your modelling, you need to first get the right people together. How to pick them? Well, like everything else it depends on the type of company and other factors but as a starter, I would suggest a mix of 40% technical people and 60% domain experts/product owners.

The second thing you need is a surface to put your sticky notes on. We have found that large electrostatic sheets work very well. This type of surface can easily stick to our office walls and can be extended quite a lot to help model lengthy timelines.

Finally, let people shape processes using stickies, multiple processes at the same time are ok as long as everyone sticks to the timeline. The workshop depending on a domain may take as short as a couple of hours or in case of a larger mature business can be a series of meetings (regardless – it will rarely be time wasted). It actually may be a good idea to have a couple of sessions, this can help you moderate them in such a way that whenever conflict arises that blocks progress you can (when possible) move on to the next process. This allows you to come back to the problematic subject in next session. Often clearing their minds and coming back to a problem next day gives people perspective and allow to reach consensus easier.

What to think about and what to avoid

While its definitely easier to conduct the workshop locally it is possible to organise an online session if needed, here are some potential tools you can use: https://mural.co/ https://miro.com/
Avoid strict definitions, naming conventions and notation. Given broad audience coming from various departments, it will likely be easier to understand and expand the context without such language boundaries
Allow disagreements but provide healthy moderation. If you cannot get the group to reach an agreement, consider moving on for a while and get back to the problem in the next session
Consider limiting the number of markers after the initial domain is shaped. This way it’s easier to moderate as people will have to take turns to expand or change the model
At the point, the domain is mostly clear to consider a bottleneck identification exercise. Ask everyone to get a marker and draw an arrow to what they think is the key process to the model. Whatever has most votes is likely a place to focus on in regard to optimizations and improvements.

Summary

While BPES is often used in the context of DDD architectural pattern it can be used in any other architecture pattern as well. Be it Microservices or even monoliths, most architectures work well with well-designed boundaries. These boundaries are exactly what will become apparent at the end of your modelling exercise. Remember that this is nothing more than a concept – you can mould it to your needs by changing or expanding notations. Alberto himself said the BPES is like pizza, use the base and add your own toppings (as long as you avoid pineapple). For inspiration, you can check the Awesome Event Storming GitHub repository to see how Mariusz Gil adapted BPES to his needs.

As always feel free to leave your thoughts in the comments box below. Happy modelling!