Event Storming: The Game-Changing Technique You Wish You Knew Sooner!
Everything you wanted to know about Event Storming! The groundbreaking guide that helps to bridge tech and business, enhancing project outcomes and team synergy!
Hello folks, and welcome to another series of Tech Setters where we discuss tech, technologies, and computer science in general. Today, we talk about Event Storming, a technique that could be invaluable not only for those of you thinking about starting your own startup but also for those working in established companies or large corporations. It's a practical tool for everyone involved in the software development lifecycle, whether you're at the drawing board of your entrepreneurial journey or navigating the complexities of existing business processes as a high-level manager.
Before we dive deep into the world of Event Storming, let's address a common problems many face during the transition to a microservices architecture, using it as a typical example. Making this leap often results in multiple questions from all involved stakeholders:
How to properly design microservices?
How to share and manage data models?
How to define the boundaries of a service?
How to determine the service context?
How to delineate context boundaries?
To duplicate or not to duplicate data across services?
How to divide into microservices based on subject areas?
What is the algorithm for transitioning to microservices?
How to avoid creating a distributed monolith?
And indeed, how to design correctly? There is no one-size-fits-all answer. If there were, it wouldn't last long before another competitor idea aimed to take the throne! However, there are best practices that have proven their worth in the field. And one such practice is Event Storming.
I invite you to dive into this journey together, keeping in mind that Event Storming could really change the game for anyone thinking about starting a business or looking to shake things up in their current company. And hey, if you're dreaming up your tech startup, you've got to check out my other post:
It ties in nicely with Event Storming, showing you how all these concepts fit together to help you navigate the tech world with confidence. On that note, let's continue into why we even need some fancy techniques for designing systems.
Why Bother Reinventing the Wheel or What is the Value of Event Storming?
Complex systems are often developed by large teams where few, if any, fully understand the entire domain of the project. Each team member might know their own piece of the puzzle, but combining these pieces into a coherent whole is challenging. Teams frequently encounter incomplete, contradictory, or incorrect requirements and often dig themselves deeper trying to solve issues with technical solutions. This happens because no technology can fix "bad" requirements.
To achieve a common understanding (sometimes called a shared mental model) of the business process of the product being developed, it's essential to bring together domain experts or SMEs (Subject Matter Experts) and equip them with an effective and understandable knowledge extraction tool. Event Storming is simply one of such tools.
Alberto Brandolini, the creator of Event Storming, describes it as a way to bring developers and business stakeholders together to collaboratively explore the domain, spending "hours instead of days and weeks." In essence, it's an opportunity to design the system in terms of business processes and divide it into bounded contextual modules, which can later form the architecture.
From the complexity of understanding, we reach a situation where requirements are incomplete, contradictory, or simply wrong. Some attempt to resolve their issues by adopting Kafka, under the assumption that it will eliminate all the problems. But the truth is, no technology can correct bad or incorrect requirements. It's particularly bad when the blame game starts. However, most often, nobody is to blame. Instead, a proper technique is needed that can help build a comprehensive common model based on the fragmented knowledge of all those involved in the development and use of the product.
The objective of Event Storming is to establish a shared understanding of the business process of the product being developed
It sounds general and a bit uninnovative, but it's straightforward.
Event Storming serves as a powerful tool for higher management by helping:
Delineate the boundaries of business processes or projects, making it clear which steps are within scope and which are beyond, thus focusing efforts and resources efficiently;
Identify all actors involved in the process, ensuring that every relevant perspective is considered in the planning and execution phases;
Provide valuable insights into the initial UI design or the enhancement of UX, leveraging the visualised flow of events and interactions;
Reveal implicit business-level dependencies that might not be obvious, highlighting critical interdependencies essential for risk mitigation and planning;
Identify bottlenecks in the process, enabling teams to prioritise solving these issues for smoother and more efficient operations;
Uncover missed events or use-cases in the process, ensuring that the developed system or solution is comprehensive and robust;
Discover primary aggregates, aiding in the understanding and modelling of the business domain more effectively for scalable and maintainable system development;
Spark discovery of innovation opportunities, providing a platform for free-flowing ideas and debate that can lead to breakthrough ideas for products, services, or process improvements.
And overall, Event Storming is a fantastic practice that simplifies future work in the realm of DDD (Domain Driven Design), microservices design, and event planning in event-driven architectures.
So, What is Event Storming? The Essence of a Collaborative Workshop
Event Storming is a workshop format for quickly exploring complex business domains, created by Alberto Brandolini, an Italian software development coach, around 2013. We can describe the format as below:
It is powerful – it has allowed me and many practitioners to come up with a comprehensive model of a complete business flow in hours instead of weeks;
It is engaging – the whole idea is to bring people with the questions and people who know the answer in the same room and to build a model together;
It is efficient – the resulting model is perfectly aligned with a Domain-Driven Design implementation style (particularly fitting an Event Sourcing approach) and allows for a quick determination of Context and Aggregate boundaries;
It is easy: the notation is ultra-simple. No complex UML that might cut off participants from the heart of the discussion;
It is fun: I always had a great time leading the workshops, people are energised and deliver more than they expected. The right questions arise, and the atmosphere is the right one.
At its core, Event Storming is a workshop with a simple structure, where domain experts and developers come together to dive deep into their domain. As the exploration progresses, participants unravel more uncertainties and hidden complexities, align assumptions with reality, and reduce the impact of these assumptions on the product's quality.
Event Storming is utilised in exploring customer experiences, designing new services, gaining insights into the operations of legacy systems, modelling complex domains, and planning microservices or event-driven architectures.
This technique is iterative by nature. The domain model can be gradually detailed and refined with each session. This approach minimises participant fatigue, allowing sessions to focus on specific issues, invite relevant experts, and take breaks for further research. It's a dynamic process that not only fosters understanding but also encourages active participation and creativity in tackling the complexities of system design.
Grammar of Event Storming: Organising Knowledge into Stories
Alright, now that we understand the value of Event Storming, why we need it, and what we can achieve with it, it's time to move on to something more practical. Let's dive into the fundamental building blocks of Event Storming, the grammar that helps us organise discussions and capture domain knowledge in a structured story rather than abstract concepts. This is where the real hands-on work begins, laying down the foundation for a successful and comprehensive exploration of our domain.
Event Storming sets a specific grammar that aids in organising discussions and capturing knowledge about the domain in a structured narrative rather than a set of abstractions. Here are the foundational building blocks, the bedrock of Event Storming:
Domain Event: The cornerstone of Event Storming, a domain event represents an occurrence within the domain of expertise, formulated as a past-tense verb. Its official color is orange. This event from the experts' world signifies something that happened in the domain being studied.
Hotspot: Used to highlight and visualise conflicts, which might stem from language discrepancies, misunderstandings, disagreements, objections, problems, or a desire to postpone deeper exploration. The official color for hotspots is crimson or red.
Timeline: This represents the sequence of events, arranged from left to right as they occur. Parallel streams of events can be laid out one beneath the other, illustrating the flow of time and interactions within the domain.
Chaotic Exploration: A phase at the beginning of Event Storming where participants individually place all the events they can think of in the order they believe those events happen. This phase encourages free thinking and generates a broad array of ideas and events related to the domain.
Enforcing the Timeline: Following chaotic exploration, this phase involves organising all events along a unified timeline and eliminating duplicates. This step transitions from broad, chaotic ideas to a structured, sequential understanding of the events within the domain.
In Event Storming, it's common to identify three main levels of exploration, each subsequent level adding to and evolving the model:
Big Picture Exploration: At this level, we're dealing with large-scale exploration. This could involve launching new products, conducting an organisational retrospective, or examining the organisation for structural changes. It's all about seeing the forest for the trees, understanding the broader context and the high-level flows that define the organisation or project.
Process Modelling: This level is focused on modelling business processes and services. After we've established the overarching narrative and identified key events during the Big Picture phase, Process Modelling zooms in on how these processes work in detail. It's here that the specific sequences of events, interactions, and flows are mapped out, providing a clearer view of how different parts of the system interact with each other.
Software Design: At this level, we transition to designing the architectural solution, ideally characterised by loose coupling and high scalability. After understanding the big picture and the detailed processes, Software Design tailors the technical architecture to support the identified processes efficiently. This phase is where the rubber meets the road, translating our understanding of the domain and processes into concrete software design decisions that will shape the development and scalability of the solution.
This exploration across the three levels – Big Picture, Process Modelling, and Software Design – is typically conducted over multiple sessions and iterations. It's important not to rush or expect to cover everything in a single session. Event Storming is a collaborative and iterative process that allows for the gradual refinement and deepening of understanding. Each session builds upon the previous ones, layering more detail and precision into the model.
As you progress through these levels, remember that the goal is to foster a shared understanding among all participants, which often requires revisiting and adjusting earlier assumptions and insights.
Now let's dive into the details of what each iteration looks like in practice.
Step 1 – Big Picture Exploration
The Big Picture in Event Storming serves as a powerful tool to either evaluate the current state of an existing business line or to explore the feasibility of a new opportunities. Its primary goal is to foster a collective understanding among participants about the vision and operational dynamics over a specific domain within the organisation.
By engaging in Big Picture EventStorming, teams can produce valuable insights that directly contribute to aligning with Conway's Law. This law suggests that organisations design systems that mirror their own communication structures. Therefore, the insights gained from these sessions can be instrumental in organising business flows that are aligned with team structures and software development practices, ultimately leading to the emergence of bounded contexts that are well-defined and effectively managed.
Workshops for Big Picture Exploration can accommodate a wide range of participants, from 10 to 30 or more, fostering collaboration across various departments and levels of expertise. Utilising a simple setup – a large paper roll laid out on a wall or table – this approach allows for a dynamic and visually engaging exploration of complex business landscapes. Participants use coloured sticky notes to represent events, hotspots, and other relevant concepts, creating a detailed map of the business domain.
Following building blocks are added on top of the foundational elements previously described (such as the Domain Event and Hotspot):
Opportunity
To balance the potential negative connotations of identifying problems (Hotspots), the concept of Opportunities is introduced. Opportunities are marked with green to symbolise positivity and potential growth areas within the domain. They are added after establishing a consistent timeline, encouraging participants to think proactively about where improvements or innovations could be made.Actor/Agent
Actor or Agent is a group of people, a department, a team or a specific person involved around a (group of) Domain Event(s). The official colour to use is a small yellow post-it.System
A system is a deployable IT System used as a solution for a problem in the domain. When we have finished making the timeline consistent, we can start mapping systems around Domain Events. There can also be duplicates and it can be anything from using Excel to some microservice. The official colour is a wide pink post-it.Value
We can add value like we would do in a value stream map, after we have made the timeline consistent. We do this to make explicit where the value is in our domain. We use the red and green small stickies to show positive and negative value.Pivotal Events
With Pivotal Events, we start looking for the few most significant events in the flow. These are often the events with the highest number of people interested, are typically marked with a distinct color or type of sticker to ensure they stand out from the rest of the events, eg.: yellow vertical sticker.Swimlanes
Parallel flows dividing the general flow of events into parallel horizontal streams based on a certain principle, for example, by parallel processes, for different actors.
Step 2 – Process Modelling: Zooming in on the Details
The goal of Process Modelling in Event Storming is to delve into and thoroughly examine a specific process. This stage fosters a shared mental model among participants, centered around the process, and assists in identifying bottlenecks within it. Process Modelling can also be applied to design new processes, services, and business lines, making it a versatile tool for both refining existing operations and brainstorming future expansions.
While some elements were introduced earlier, let's define additional building blocks used in Process Modelling:
Command
A decision, action, or intention that can be initiated by an actor or an automated process, formulated in the infinitive. The official color for Commands is blue, representing the actionable steps that drive processes forward.
Policy
Essentially a rule or reaction, articulated as "if A happens, then do B." Policies can be manual or automated processes. The official color for Policies is lilac, symbolising the conditional logic that governs the process flow.
Read Model
The information used by an actor to make decisions. Defined by domain experts, the Read Model is crucial for understanding the context in which decisions are made. Its official color is green, indicating the informational inputs into the process.
The process begins with collecting events that occur within the business, which are then laid out in chronological order. Following this, Commands that trigger these events and the Actors who issue these Commands are added. The model is further refined with Policies and Read Models. For a more detailed explanation of how to read the Process Modelling Board, please refer to the picture below:
This simple grammar facilitates a focused exploration and helps develop a common language between development and business teams. As a result, the code, design, and architecture are informed by a model that is deeply rooted in the domain, reflecting the real-world intricacies of the business process. Through Process Modelling, teams gain a detailed understanding of the process mechanics, enabling them to design more efficient, effective, and aligned solutions.
Step 3 – Software Design: Integrating Technical Implementation with Business Processes
In the 3rd iteration of Event Storming for Software Design, we further explore by integrating technical implementation details within the context of business processes. This approach leads to a high-level solution schema that smoothly transitions into the design phase.
The Software Design phase of Event Storming introduces an additional element critical to refining the technical architecture: the Aggregate.
Aggregate: A term borrowed from Domain-Driven Design (DDD), an Aggregate represents a cluster of entities that are treated as a single unit. It possesses invariants for the group of objects it comprises, rather than for any individual object. The official color for Aggregates is yellow. While it's not always necessary to introduce DDD terminology into Event Storming, in cases where it might not be appropriate, alternative phrases like “constraint” or “business rule” can be used to convey similar concepts.
The full structure of the Event Storming model at the Software Design level involves:
Identifying Aggregates and understanding their role and boundaries within the system;
Mapping out Commands related to each Aggregate, the Events they trigger, and the Read Models they influence.
These components, including the Aggregate, its related Commands, Events, and Read Models, can potentially be delineated into a microservice. While this is not the only method to define the boundaries of a service, it serves as a solid example of how to approach service delineation.
Through this approach, Software Design in Event Storming not only aligns the technical architecture with business processes but also provides a clear pathway for translating the intricate details of the domain into a coherent and scalable software design.
It’s important to mention that this phase effectively bridges the gap between the theoretical models developed during Big Picture and Process Modelling stages and the practical requirements of implementing a robust technical solution.
Laying the Foundation with Event Storming
In our today’s article of Tech Setters, we took a close look at Event Storming, covering its fundamental terminology and key building blocks. The final map you get from a successful Event Storming session can serve as more than just a detailed analysis; it can be transformed into a strategic roadmap for the entire company. This roadmap not only guides the technical team through the complexities of system development but also aligns business objectives with technological capabilities, ensuring that every step taken is a step towards to reaching business goals. By visualising processes, identifying bottlenecks, and highlighting opportunities for innovation, Event Storming facilitates a collaborative environment where business strategy and technical execution converge, setting the stage for sustainable growth and competitive advantage.
As we wrap up, let me give you some final tips to make your Event Storming sessions even better:
Prepare Space and Provide the Right Tools – conducting the workshop in person is ideal, utilising a large, spacious wall where participants can physically place stickers;
Provide Simple Examples – despite the very simple rules, people often do not understand what to do right away. The rules should be visible to everyone. Once again – clearly visible! It's also advisable to show what the final result should look like right from the start;
Don’t start modelling from the corners;
Initially, if there are many participants, you may divide them by product or shared responsibilities, as this facilitates a faster process in the beginning;
Forget about roles and contracts – they should not limit the search for solutions;
Business people should place stickers first! Otherwise, the conversation quickly slides into technical implementation;
Commands can be placed in the backlog;
Ask Lots of Questions: What happens if something goes wrong? Does this always happen or just sometimes? What needs to happen for this event to occur?
Now, let's pivot to what Event Storming isn't a silver bullet for.
What Event Storming Does Not Replace:
A Stand-in for Business Requirements, Technical Specifications, and Documentation: While addressing a minor features may not be a problem, embarking on larger projects without detailed business requirements, technical specifications, contracts, and other documentation can lead to operational chaos.
Substitute for Process Analysis: Ideas generated during storming sessions may initially appear viable but require further refinement. Some events might be too complex, expensive, or not align with marketing strategies, emphasising the need for comprehensive analysis.
Replacement for Architecture Design: The modelling undertaken in storming sessions does not provide a complete overview of the future architecture. The nuances of system contracts, physical divisions, authorization mechanisms, and more are left unspecified, which underscores the necessity for explicit architectural design efforts.
If you've journeyed with me this far, hats off to you! You're now equipped with the insight not just to navigate the stormy seas of system design but also to impress both management and business teams with your Event Storming prowess. By highlighting how this technique can bridge the gap between technical teams and business strategy, you're set to drive meaningful conversations that can shape the future of projects and products. Stay curious, stay engaged, and remember – in the intricate dance of technology and business, be like Event Storming: insightful, collaborative, and, unlike my jokes, always on point!
🔍 Explore more