image from What is Event Storming? An introduction for beginners

What is Event Storming? An introduction for beginners

Event Storming is a quite new, but increasingly popular method for collaborative discovery and modeling of processes within complex business domains. It teaches us how to describe the operation of our system using events.

The technique has been described for the first time in 2013 by Albert Brandolini, and very quickly won over the hearts of people associated with Domain Driven Design. In the latest ThoughtWorks Technology Radar, Event Storming has been indicated as the recommended method for modeling the business domain in IT systems.

This article is mainly on IT systems, and we will focus on such cases in this post. Nevertheless, it’s important to remember that Event Storming can also be used for general structuring of knowledge about processes in an organization or company - a post on this topic is coming soon.

Conducting workshops does not require specialized knowledge of large books and dozens of videos - it all starts with an orange piece of paper.

Domain event – the heart of the workshop

Event Storming is based on domain events - facts, that describe the operation of our system. We write down each event on a piece of paper and put it on the wall. Below you can find my quickly written event - in our example it’s adding a product to the cart.

Each post-it contains important information about an event that occurred in the system. All system participants, (almost) independently, place their notes on a designated wall or board. Depending on the number of events, result of this phase may look like this:

It might seem overwhelming at first glance but believe me - the result is phenomenal. In a few moments, our colleagues and teammates dump almost all (or at least a large chunk) of the knowledge about their system onto a common space.

The next step revolves around structuring the above.

Structuring

After placing all the events on the wall, we start organizing and arranging the cards in such a way that our events are combined into common business processes or use cases. Later we can analyze each of them separately, from beginning to end, or vice versa, and therefore gain more and more knowledge on how our process is carried out.

To make spotting the patterns easier, we can use cards in different colors to visualize additional information about the system, for example:

  • Light yellow – notes describing a broader topic
  • Pink – problems / uncertainties / risks
  • Lilac – external systems
  • Small yellow ones – actors / people / departments
  • Green – opportunities for development/improvement
  • Blue – commands

I recommend introducing new colors into the workshop gradually, only when we need to obtain a specific piece of information from our colleagues.

Workshop goals

The result of a well-conducted workshop is a full view of our system, outlined business processes and better understanding of the way they interact with users and external systems. Such knowledge helps us with:

  • Gaining deeper understanding of the system, establishing a common perception between many employees/stakeholders
  • Visualizing how the system works, making it easier to to divide it into smaller parts / microservices
  • Sufficiently rapid exchange of knowledge to, for example, introduce new programmers to work on the system
  • Analysis of current system problems along with ideas on how to fix them
  • Creating a plan for adding new functionality to the current system
  • Predicting the possibility of developing our system and achieving greater profits

Sample workshop results

We conducted one of many such workshops for our client. The task was to understand how a large, monolithic system works and plan to divide it into smaller parts. Below is the result of our workshop (photo contains only half of the outcomes):

The workshop lasted several hours, let us understand:

  • What parts of the system are trivial, and we don’t need to worry about them
  • What parts of the system should be separated into independent modules/microservices
  • Where should the boundaries of such modules be?
  • How should these modules communicate?
  • How to collect data between modules to avoid too frequent communication
  • What are the real and potential problems with the current system that we need to solve
  • Which external systems are causing problems

All workshop participants were pleased with the results but amazed that it was all achieved in one day.

After such an expansion of knowledge, we could plan and divide the next task and start implementing a better solution for our client.

A broader look at Event Storming

As the example clearly shows, Event Storming workshops let you visualize how our system works through the simultaneous and joint exchange of knowledge between colleagues. Each person is committed to sharing knowledge about their area of work, providing as much information as possible.

What’s noteworthy is that Event Storming has a very low entry threshold, so everyone can start actively participating from the first minute, as it’s all based on “business events”. After a brief explanation of what a business event is, we are ready to get to work.

Another dimension to consider is time. By parallelizing work and dividing the group, we can work more effectively, making the workshops shorter and giving measurable results.

How to conduct such an Event Storming workshop

There is plenty of content on how to organize an Event Storming workshop (article /video), not to mention the most important one – thebook. In addition, a very interesting repository was put together by Mariusz Gil on GitHub in the repoAwesome EventStorming.

After familiarizing yourself with the basics, it’s time to get to work! If you are interested in this topic, I recommend myEvent Storming workshops or checking out other articles on this topic.

comments powered by Disqus