EventStorming builds shared understanding for better software

 
The silent misalignment between what is imagined and what is built becomes one of the biggest costs in software development, like I wrote in my recent blog post: Software’s real cost: building the wrong features. So how do you make sure everyone shares the same understanding before development begins? 

Towards efficient conversation

An effective way to build shared understanding is EventStorming, a visual and highly collaborative workshop format created by Alberto Brandolini. Instead of diving straight into features or user interface mock-ups, participants map out the events that matter in their domain: moments such as “customer placed an order,” “payment failed,” or “invoice sent.” 

Each event tells part of the story. As these moments are mapped out to a timeline, patterns start to appear: sequences, dependencies and bottlenecks that are often invisible in day-to-day discussions. 

What makes EventStorming powerful is its inclusiveness. You do not need to know how to code; you only need to know your business. Developers learn directly from you, designers see how the system behaves and everyone sees how decisions connect across processes. The result is a fast, efficient conversation where hidden rules and edge cases surface early. 

Levels of EventStorming

EventStorming can be used at various levels of detail depending on your goal. At one end of the spectrum it explores an entire organisation; at the other it dives deep into the technical design of a single service. The three levels reinforce one another, helping teams move from discovery to design while keeping business language and software models aligned. 

The following illustration depicts the process-modeling level, where events (orange) produced by external systems (pink) or internal components (light yellow) trigger policies (purple) to initiate commands (blue) that in turn shape the system. Read models (green) translate events into views, while hotspots (magenta) signal areas needing deeper discussion. 

Process-level EventStorming diagram

The hidden cost of translation 

Beyond aligning people, EventStorming exposes the cost of translation between business language and code. Business experts describe their world with terms like customers, orders, policies and invoices. Developers often invent their own vocabulary, with classes like Account, TransactionProcessor or BillingJob.

Individually these choices seem harmless but over time they create two different realities: one in conversation and another in code. When the business changes, it takes extra time and effort to trace how concepts map into the system. 

What you discover  

The value of EventStorming lies not only in the model that emerges but in what happens while you build it together. Mapping events forces you to make implicit knowledge explicit and to confront assumptions early. Some of the benefits include: 

• Alignment on reality: everyone sees how the business really operates rather than how they assume it does 

• Early discovery of edge cases: hidden rules, exceptions and responsibilities surface before development starts 

• Collaborative ownership: design, engineering and business perspectives are considered at the same time, leading to more balanced solutions 

• Bounded contexts: complex problems are broken down into smaller, clearer areas that are easier to reason about and to implement independently 

• Shorter feedback loops: the distance between idea and understanding shrinks from weeks to hours, reducing the cost of wrong features 

Real-world impact 

At Twoday we recently helped a client adopt Domain-Driven Design in a complex domain while maintaining high development velocity and quality. After introducing EventStorming, leaders noticed a clear change: engineers and designers became much more engaged with the problem domain once they had a tool that helped them connect with domain experts. They started to see and collaboratively solve domain-related problems instead of merely implementing ready-made specifications.

Unused features decreased and the quality and maintainability of the code improved as it began to use the same terminology as the domain experts and aligned more closely with the underlying models.

From misunderstanding to clarity  

• A map of your domain that everyone can read and contributes to 

• A common vocabulary that bridges business and technical work and can be carried into code 

• A growth-ready design that links discovery to implementation through DDD concepts such as bounded contexts, commands and events 
  
  

The resulting artefact of a Process Modelling EventStorming

It is not magic but it is remarkably effective at turning “we should have talked earlier” into “we finally understand this together.” At Twoday we use EventStorming to help our clients uncover clarity and shared understanding before development begins and to deepen that understanding iteratively as we build together. 

Key takeaway: The best way to reduce the cost of wrong features is to make sure everyone understands the right problem and speaks the same language from the start. 

All images used in this article are courtesy of Avanscoperta. 

About Simo Roikonen

Simo is a Global Principal Architect in Global Digital Engineering at Twoday, with over 20 years of experience designing and building resilient, evolvable software systems. He joined Twoday in Finland in 2020 and works across teams and business units in hands-on architect and advisor roles, leading modernization efforts and solving complex technical challenges. Simo has a strong focus on Domain-Driven Design and on designing distributed backends that deliver low latency and scale, while also contributing to global initiatives that strengthen engineering excellence and modern software development across Twoday.

Simo Roikonen, Global Principal Architect