An introduction to the fun and effective workshop technique that unlocks heightened levels of collaboration across silo and specialization boundaries.

In the many years I’ve been working on software development projects I witnessed countless problematic situations caused by some misunderstanding or miscommunication around requirements gathering. After all, there’s no commonly accepted gold standard for documenting requirements, let alone in a way that would be digestible to all the different parties involved.

However, around a year ago, I underwent training that allowed me to add yet another hat to my repertoire—that of an event storming facilitator. This completely changed the way I work with requirements, and, having now applied event storming in a number of projects already, I can attest to its immense effectiveness.

In this article, I’m going to give a quick overview of event storming and briefly explain:

• Why use event storming?
• How does event storming work?
• What are the key wins of event storming?

Why use event storming?

In essence, event storming is a workshop technique that allows non-technical subject matter experts and engineering teams to collaboratively explore complex business domains. Originally conceived by Alberto Brandolini, it has evolved greatly over the last decade thanks to its simplicity and flexibility. Today, event storming comes in a variety of styles suitable for different purposes. This inherent agility means that it brings numerous benefits to the table:

Better grasp on complexity

Today’s businesses, especially at the enterprise level, are characterized by highly complex interactions, both internally and consumer-facing. Event storming provides a quick and easy way to visualize complex business processes at various levels of detail, consequently making this immense complexity manageable.

Close collaboration with non-technical stakeholders

Event storming considerably eases the friction between business/product stakeholders and engineers. The engaging workshop format quickly elicits key knowledge from non-technical stakeholders. Healthy discussions ensue as the knowledge is made visible on a virtual whiteboard, thus creating a shared understanding.

Accessible, long-lived, visual documentation

The output of the event storming workshops in the form of a business process model serves as an easily accessible reference point for development teams. Being a crystal-clear, single source of truth on requirements, it allows engineers to stay on track throughout the project.

Better collaboration between engineering teams

In the age of microservices and distributed systems, software development teams can become increasingly siloed. Event storming facilitates communication between engineering siloes and brings greater awareness of the broader business domain context to the respective teams.

Clean and maintainable software design

The business process models that emerge from event storming sessions can be directly translated into software models, especially when applying the event-driven architecture pattern. Event storming considerably facilitates the design and development of event-driven and event-sourced systems that are clean, maintainable, and that can scale practically infinitely.

Test automation support

Event storming can facilitate test automation practices. This is because the business processes defined during the event storming sessions clearly describe the expected behavior of a software system. Having requirements recorded in this way makes it easier for engineering teams to create appropriate automated tests.

Legacy systems modernization

Legacy systems can often become a black box that’s difficult to make sense of. In modernization projects, event storming helps map out the business processes handled by the legacy system, as well as uncover problems that need to be addressed and identify which parts of the system can be kept intact.

How does event storming work?

In a nutshell, event storming consists in visualizing business domain and software models using different-colored sticky notes placed on a virtual (or real-life) whiteboard. The event storming facilitator moderates the group discussion among the relevant subject matter experts, both technical and non-technical.

Event storming exploration takes place at three different levels:

1. Big picture: the highest level, which focuses exclusively on identifying and organizing domain events.
2. Process modeling: within a selected business domain, business processes are visualized and documented in detail.
3. Software design: the business processes are translated into software models that can then inform delivery.

Big picture event storm

This style of event storming is where non-technical subject matter experts are the most involved. The first step is to name all the possible domain events that happen within a business. A domain event is defined as an interaction that is meaningful on a business level. In a simplified example, identifying the events in an airline business could look something like this:

Next up, we start organizing the events on a timeline, so as to create a sequential storyline:

In the step that follows, the subject matter experts are asked to identify certain pivotal events which mark the beginnings and endings of the different “chapters” of our business narrative:

Finally, this leads to identifying and naming the relevant bounded contexts, which are essentially specific business domains within an organization:

Process modeling

Modeling a business process takes place within a specific domain. This means that we continue working with the events that were identified during the big picture event storm, but only within the so-called domain boundary, so as to avoid being overwhelmed by too much complexity. Continuing the simplified airline example, a process model could look something like this in the case of the Loyalty domain:

The different-colored stickies aim to steer and direct the flow of events that was identified within the big picture event storm. The participants of the workshop discuss concerns such as sets of business rules (policies), the actions (commands) that produce the events, the data that’s needed along the way, or the external systems involved.

Software design

Once a business process model is established, it can be further refined, so as to cover in detail more technical concerns related to software design and development. The eventual outcome is that we arrive at a robust software model that serves as a blueprint for development. The different event storming concepts are mapped to actual implementation tasks, contributing to a predictable and manageable delivery process.

With event storming, the transition from business process modeling to software design works particularly well with the event-driven architecture pattern, and most notably for event-sourced systems. At Xolvio, we’ve been perfecting this transition to be as effective as possible while developing event-sourced applications for a number of enterprise clients over the years.

The result of this experience is the Domain Development Kit, a lightweight application library that facilitates moving from event storming sessions to event sourcing implementation.

The finite set of elements pictured above (the DDK palette) can be used to develop clean and maintainable software systems of any complexity. The main advantages of event-sourced applications include:

• Loose coupling of systems and separating business logic
• Truly distributed architecture with asynchronous communication
• Outstanding scalability
• Built for integration
• High throughput and low latency
• Fault tolerance, high availability, and resilience
• Next-level business intelligence

What are the key wins of event storming?

Earlier, I listed a number of reasons why event storming is extremely useful to complex businesses. However, if I was to pinpoint the biggest gains associated with event storming, then it ultimately boils down to the following:

Securing organization-wide alignment and cross-functional collaboration on software initiatives

Big picture event storming tremendously helps connect organizational silos, both within an engineering organization itself and in the enterprise at large. This is crucial for company-wide initiatives such as GraphQL adoption, which are particularly hampered by the lack of stakeholder alignment. Event storming produces shared understanding and makes complexity manageable, while also providing the ability to dig deeper within the different business domains, so as to tackle more specific problems with precision.

Rapid development of GraphQL-native event-driven systems

As outlined above, while event storming is overall an end-to-end technique to facilitate going from high-level requirements to low-level software design, it is particularly useful with the event-driven architecture pattern. To add to the many benefits of such systems that I mentioned before, it should be noted that event-driven microservices easily integrate into GraphQL APIs, making event-driven architecture a fitting choice for organizations that are building an organization-wide supergraph.

Further resources

1. 50,000 orange stickies later: an entertaining and informative presentation from the event storming originator, Alberto Brandolini, which gives a more detailed overview of the practice.
2. Event Storm to Production Supergraph: blog post outlining the Xolvio approach to applying event storming in the context of federated GraphQL API design and development.
3. Introducing Schema Storming: GraphQL Summit session recording presenting a novel technique to accelerate demand-oriented GraphQL schema design that was inspired by event storming.