Event Modeling: Another Game-Changing Technique You Wish You Knew Sooner!
Is Event Modeling the secret sauce for faster, better software development? Uncover how to improve KPIs, optimize system performance, and reduce costs – all in one, while building scalable software!
Hello everyone, and welcome back to another episode of Tech Trendsetters where we discuss visionary ideas, technologies and trends, and how they intersect with business!
Last week, I had the absolute pleasure of meeting Adam Dymitruk, the mastermind behind Event Modelling, in person at a workshop here in Berlin. It was incredibly inspiring and let me tell you, this guy is onto something big!
But before we dive into the nitty-gritty of Event Modeling, let me ask you a question: Have you ever started a new project where everything looked shiny and the work was easy and enjoyable? A honeymoon phase, right? But then, suddenly, after 6 months, it becomes unrealistically hard, business starts to complain and every change takes years to integrate. If this sounds all too familiar, then you're in the right place.
In today's episode, we'll explore how Event Modeling can help you tackle these challenges and ensure that your projects remain aligned with your business values and goals (even as they grow and evolve over time). By the end of this episode, you will understand:
The core concepts and benefits of Event Modeling;
How Event Modeling connects to Key Performance Indicators (KPIs);
Practical tips and tools for implementing Event Modeling;
How Event Modeling can save your business money;
Real-world examples of Event Modeling in action;
Grab a cup of coffee and settle in, because this is going to be again a long but worthwhile read.
Faster, Better Software with Event Modeling
It has been already a few decades how organizations and businesses are constantly seeking ways to develop and deliver software systems more efficiently and effectively. Traditional approaches to requirements gathering and system design often fall short, leading to communication breakdowns, missed requirements, and most importantly – suboptimal solutions. This is where the concept of Event Modeling comes as a new potentially transformative solution.
Event Modelling has its roots in the work of Greg Young on specifying long-running processes in CQRS/ES systems back in 2008. Adam Dymitruk, who had been working closely with Young at the time, built upon these ideas. He integrated Alberto Brandolini's Event Storming sticky notes and collaboration approach to adopt a workshop format. The final piece was incorporating UI/UX aspects to make the resulting artifacts resemble a movie storyboard.
The fun part is that initially they called it "Single-Flow Event Storming," but later on, as the idea developed, the more concise term "Event Modeling" emerged.
The term "Event Modeling" itself was coined after the Event Storming Summit in July 2018 in Bologna, Italy. At this gathering, it became apparent that Event Modeling, while similar to Event Storming in some ways, differed significantly in its approach and goals. Event Storming primarily focuses on discovering the problem space, while Event Modeling creates a blueprint for a solution. And because Event Modeling sessions are relatively quick, it can also serve as a tool for rapidly exploring the problem space by iterating on potential solutions.
Hey, even the best of us need a reminder sometimes! If the term “Event Storming'“ is a bit fuzzy, no worries. I’ve got you covered with another episode where we break it down and explore its awesome potential:
The Core Concepts of Event Modeling Methodology
As I dove deeper into Event Modeling, I realized it was much more than just a new set of notations and diagrams. It represented a fundamental shift in how we approach software design and development – one that puts events and business outcomes front and center.
I remember one particular project where this really hit home for me. We were working with a large corporate company to modernize one particular sub-system. No one has any idea how it works.. The business had been struggling with long cycle times, manual handoffs, and a lack of visibility into the end-to-end process. The existing software was mostly what we call today a “legacy code”. Nobody wanted to take responsibility.
When we introduced Event Modeling (or at least a some sort of it), it was like a lightbulb went off for the whole team. We started by mapping out the key business events in the process – from start to finish. Putting these events on a timeline helped everyone to see the big picture and identify opportunities for streamlining, automation and reducing complexity.
As we elaborated the event flows and added UI mockups, the business stakeholders got more and more excited. They could see how the new system would enable faster, more transparent processes, potentially reducing costs (which would lead to smaller allocated budgets, a prospect that made some senior managers absolutely ecstatic about). Later on, they even started to suggest new features and optimizations based on the emerging model.
It’s worth to remember that effective communication and collaboration between different stakeholders are crucial for the success of any project. Event modeling effectively can help to bridge the gap between business requirements, user experience design, and technical implementation. As Adam explains:
I wrote my first event store in 2009 and have been doing message based architectures purely for any project since then. A lot of the challenges are not technical – they are always people problems and communicating what you're trying to do. If you don't have buy-in from most people in the company, especially leadership positions, you're going to have a tough battle
The Event Modeling challenges the traditional development approach by embracing the fundamental nature of information systems: they are driven by events. At its core, event modeling involves breaking down a system into a series of discrete events, commands, read models, and UI elements. These elements are arranged both chronologically and into a swimlanes, forming a visual representation of the system's behavior over time.
Some of the key benefits of Event Modeling I find most valuable are:
Providing a shared language and understanding for business and technical stakeholders;
Capturing requirements in a concise, visual way while still retaining precision;
Enabling parallel, decoupled development of UI and backend systems;
Highlighting opportunities for UI/UX innovation;
Ensuring information completeness and explicit dependencies;
Reducing rework by getting the model right before implementation;
Simplifying the path to an event-driven architecture;
Enables the responsible architecture that treats software like accountants treat money, with clear expectations and the ability to handle exceptions gracefully.
So far, event modeling has been successfully applied in various industries and domains. As we continue to explore the full potential of it, I expect to see even more innovative applications and breakthroughs in the years to come.
Connecting Events to Key Performance Indicators (KPIs)
One of the most powerful aspects of Event Modeling is its ability to connect the dots between individual events and the overall business objectives. By mapping out the flow of events and the resulting state changes, you can start to see how each action contributes to (or detracts from) your key performance indicators (KPIs).
For example, let's say one of your primary KPIs is user acquisition. With an event model in place, you can trace the path from initial user contact to successful signup. You might discover that a particular sequence of events correlates strongly with higher conversion rates. (e.g., Landing Page Viewed → Sign Up Button Clicked → Account Created; simplified, yet I hope you got the idea). Armed with this insight, you can focus your efforts on optimizing that specific flow to drive more signups.
Similarly, if you're tracking a metric like Monthly Recurring Revenue (MRR), you can use your event model to identify the events that contribute most to that figure. Perhaps you find that users who trigger a "Feature X Used" event within the first week of signing up are more likely to convert to paying customers. Or maybe you notice that a high frequency of "Support Ticket Created" events tends to precede customer churn. By surfacing these correlations, Event Modeling helps you prioritize the actions that will have the greatest impact on your bottom line.
But the benefits don't stop there. With an event-driven architecture in place, you can actually instrument your system to track these KPIs in real-time. Each event can increment a counter or update a dashboard, giving you a live view of your business health. You can set up alerts to notify you when certain thresholds are reached, or when a particular sequence of events occurs.
This level of visibility is invaluable for data-driven decision making. Instead of relying on intuition or lagging indicators, you can respond to changes as they happen. You can run experiments and see the results immediately reflected in your KPIs. You can spot trends early and adapt your strategy accordingly.
In a sense, Event Modeling is not just a technique for software design – it's a framework for business intelligence. By making the connection between events and KPIs explicit, it helps you align your technology with your strategic objectives. It gives you the tools to not just build the right thing, but to build the thing that drives results.
So if you're not already thinking about how your events tie back to your key metrics, now is the time to start.
The Power of a Unified Model
Many companies do implement manual event tracking, but it's important to emphasize that no manual setup that needs constant oversight can be as effective as one unified model of your business that incorporates all aspects of the system as they arise. Software is constantly evolving, and trying to manually track events and their impact on KPIs can quickly become a cumbersome and error-prone process.
Reflecting back on the domain-driven design (DDD) principles – with Event Modeling, you have a living, breathing representation of your system that automatically stays in sync with your code. As new features are added or existing ones are modified, the event model is updated accordingly. This means that your understanding of how events flow through your system and impact your business metrics is always up-to-date.
There's no ambiguity about what events are important, how they're tracked, or what they mean for the business. Everyone can see, in real-time, how their actions are contributing to the company's success.
The 7 Steps of Event Modeling
So how do you actually do Event Modeling in practice? There are 7 key steps to follow:
The first step is to get everyone together and brainstorm all the events that could happen in the system you are designing. For example, if you were building an invoice management system, events might include: invoice created, invoice sent, invoice paid, invoice exported, etc. The goal is to capture all the key facts that would be stored over time.
Arrange the events into a plausible timeline. This becomes the "plot" of your system's story. Review it to make sure the sequence of events makes logical sense from beginning to end. Identify key events that are most important to the core of the system.
Now it's time to make the event model more visual and accessible. Add wireframes or mockups for each step showing the key UI screens. This is critical to get the UX/UI perspective represented. Every key data field should be accounted for so you can trace the full flow of information.
With the storyboard taking shape, the next step is to identify the points where the user needs to provide input to change the state of the system. Connect the relevant UI elements to blue "command" boxes and then to the downstream event that gets stored. This makes the intention explicit.
On the flip side, you also need to show how the accumulated events get projected into "read models" (green boxes) that provide state views back to the UI. For example, include an "Outstanding Invoices" list or an "Invoice Aging" report. Draw lines to connect these read models to their corresponding events.
With the end-to-end flow mapped out, you can now apply the Conway's Law to organize the events into swimlanes representing different subdomains or business capabilities. This allows you to align the software architecture with team boundaries for autonomy and ownership.
Finally, with the visual model in place, you can efficiently zoom in and specify the details for each step. Use "given-when-then" (GWT) statements to define the pre and post conditions and acceptance criteria, just like in BDD. Keep it focused and tied to the context of each step.
By following this process, you end up with a lightweight yet powerful blueprint for your software system including:
The big picture and the details;
The business logic and the user experience;
All the key perspectives reflected in one integrated view that serves as:
a shared map;
system documentation;
and ubiquitous language;
The Building Blocks – Bringing Above Concepts to Life
Adam Dymitruk, the creator of Event Modeling, provides a comprehensive overview on his website – I highly encourage you to read it firsthand to get the full technical details. He emphasizes that the method uses 3 core moving pieces and 4 patterns based on 2 fundamental ideas. However, in practice, I've found that there are at least 6 distinct moving parts you'll encounter, and the number of patterns can expand even further depending on the complexity of your use case.
Moving Parts:
Commands (Blue Stickies): These represent user actions that intend to change the system's state. Examples include "Approve Invoice," "Reject Invoice," or "Submit Invoice for Payment";
Events (Orange Stickies): These are the facts that get recorded as the system evolves. They're always in the past tense, like "Invoice Approved," "Invoice Rejected," or "Invoice Paid";
Views/Queries: These display information to the user, like a list of pending invoices, an invoice's details, or the total amount due;
UX/UI/Wireframes: This is where the visual magic happens. Wireframes or mockups give a tangible representation of the user interface at each step of the process.
Swimlanes: These visually organize events into different categories, often representing different actors or subdomains within the system (e.g., "Approver," "Accountant," "Payment Processor");
Aggregates: These are clusters of related events and commands that represent a cohesive unit within the domain model (e.g., an "Invoice" aggregate could encompass all events and commands related to a single invoice's lifecycle).
Key Patterns:
State Change: This is the heart of Event Modeling. A command triggers an event, which updates the system's state. For example, the "Approve Invoice" command triggers an "Invoice Approved" event, changing the invoice's status.
State View: This is how the system communicates its current state to the user. For example, a dashboard view might display the total number of pending invoices or the total amount due based on past events like "Invoice Submitted" and "Invoice Paid."
Translation: This pattern might be used when integrating with a bank's payment system. An "Invoice Approved" event could be translated into a "Initiate Payment" command for the bank or vice-versa scenario.
Automation: This could be used to automatically send notifications to approvers when new invoices are submitted, or to trigger payment processing when an invoice's due date arrives.
Reducing Costs Through Event Modeling
One of the most compelling benefits of adopting Event Modeling is its potential to significantly optimize software development costs. By providing a shared language and clear blueprint that aligns business and technical perspectives, Event Modeling helps avoid many of the pitfalls that lead to expensive rework and delays.
As Martin Fowler points out, the biggest waste in software development is building the wrong thing. Traditional requirements gathering approaches often result in miscommunication and missed requirements. The disconnect between business needs and what gets implemented can be costly.
Event Modeling directly addresses this by capturing requirements in a concise, example-driven way that is accessible to all stakeholders. The visual, timeline-based approach ensures that key workflows and dependencies are made explicit. Misunderstandings are surfaced early before any significant development effort is expended.
The ability to iterate rapidly on the event model also reduces waste. Alternative solutions can be explored and validated with the business quickly, without having to make expensive code changes. Getting the model right upfront dramatically reduces the likelihood of going down the wrong path.
But. Once development begins, the event model serves as a documentation project, keeping everyone aligned and pulling in the same direction. The clear separation of commands, events, and views enables decoupled, parallel development of UI and backend components. Teams can move faster with less coordination overhead and merge conflicts.
Over the full development lifecycle, Event Modeling tends to result in a flatter cost curve compared to any traditional or modern approaches. The upfront investment in modeling pays dividends by reducing rework in later stages. This is however an old problem we discussed previously. Design Stamina Hypothesis, where better design pays off in weeks, not months:
Overall, all facts pointing out that for organizations to optimize development spend, Event Modeling offers a proven, lightweight approach to building shared understanding and doing the right things, the right way.
Practical Tips for Getting Started with Event Modeling
The beauty of Event Modeling lies in its accessibility. If your organization is looking to implement a new service, consider assembling a team to dive into Event Modeling and dedicate a day or two to creating a model. This is a minimal investment compared to other practices, and the team members can quickly become internal experts, leading similar sessions throughout the company. Since it doesn't require extensive theoretical knowledge, it's one of the easiest disciplines to integrate into your organization.
In the following section, I'll share a list of practical tips that I've found invaluable in my own experience. By sharing this information with you, I hope to help you navigate the world of Event Modeling more effectively and efficiently.
Choosing the Right Tools
While Event Modeling can be as simple as sticky notes and a whiteboard, from my experience, it's never enough to have just a physical whiteboard. Digital tools offer significant advantages for collaboration and scalability. However, the choice of tool depends on your specific needs and team preferences:
Miro: Ideal for rapid prototyping and remote collaboration. Miro's strength lies in its simplicity and ease of use. There are multiple of plugins available specifically for event modeling – it's perfect for quickly capturing ideas and facilitating brainstorming sessions. However, Miro is limited in terms of flexibility and advanced functionality like layering, grouping, or bulk renaming of elements.
Figma: Offers a more sophisticated environment for Event Modeling. Its robust grouping, layering, and visibility features allow you to create complex models and tailor views for different audiences. Figma's popularity among designers also makes it a natural choice for integrating UI/UX aspects into your model. However, it still might be not flexible enough for deep-dive technical explorations. Nonetheless, I would recommend this option as go-to solution, especially if you never had the experience with event modelling.
Prooph Board: My fellow friend Alexander Miertsch put his heart and soul into creating Prooph Board, recognizing the need for a specialized tool that suits for mature technical users seeking maximum precision in architectural decisions. Prooph Board, and similar tools in this category, often include advanced features like domain-driven design (DDD) integration, code generation, and simulation capabilities. These tools are best suited for teams and projects where these advanced features are essential and event modeling process is widely adopted as an every-day practice.
Start with a Bounded Scope and Involve the Right People
When you're first trying out event modeling, it can be tempting to try to model your entire system at once. Resist this urge! Instead, start with a single, well-defined user journey or business process. Invite one or two business experts who deeply understand the domain.
By focusing on a bounded scope, you make the modeling process more manageable and ensure that the team can see tangible progress quickly. You can always expand to other areas of the system later. Start small, then iterate.
Integrating with Other Systems
No system exists in isolation. Event modeling provides patterns for integrating with external systems in a clear, business-friendly way.
When receiving data from an external system, it's helpful to translate that information into a form that is more meaningful within your own domain. For example, if our hotel system receives GPS coordinates from guests who have opted in, we wouldn't want to use raw latitude and longitude in our system. Instead, we would translate those into more meaningful events like "Guest left hotel" or "Guest returned to room".
This translation layer is represented visually in the event model, making it easy for everyone to understand how external data is being interpreted and used. If you familiar with the term – it's your anti-corruption layer, – without needing to explain that technical aspects to business stakeholders.
Use Real Examples and Data
Abstract discussions can only get you so far. The real data is a king. To really stress-test your model and ensure it matches reality, use concrete examples and real data wherever possible. Just be sure to anonymize any sensitive information!
To illustrate the power of Event Modeling, let's consider a core-banking scenario you might encounter: designing a banking system for processing transactions (inspired by a recent talk with a fellow Banking Platform Architect, Tristan Holl).
A key challenge in this domain is defining aggregate boundaries. Should the "account" be the aggregate, or the "transaction"? The choice has implications for transactional consistency and overall system performance. Event Modeling can help visualize the flow of events and commands, making it easier to identify potential bottlenecks and race conditions.
For instance, modeling a transaction as an aggregate might lead to a more streamlined process with smaller aggregates, but it could introduce race conditions when checking account-related invariants like available balance. This insight, gained through the visual clarity of Event Modeling, can guide architectural decisions and lead to solutions like implementing a "money-in-flight" cache.
This way, event modeling allows you to see all the events in the system like points on a map. This holistic view can help you identify potential optimizations, spot hidden dependencies, and ensure that the system remains consistent and reliable even under high load.
Make It Fun!
Finally, remember that event modeling is fundamentally a creative, collaborative activity. So keep it simple, and.. make it fun!
TLDR;
At its core, Event Modeling is really about embracing the fundamental nature of information systems. When you start with events, you can derive the macro and micro views you need. Zoom out to see the big picture flow across boundaries. Zoom in to see the step-by-step logic and data lifecycle. It's all there in one navigable model.
It allows you to incrementally grow an organic model that reflects reality. From my experience – that’s a rare thing in software. With an event-centric blueprint, you also have a natural path to implementation using an event-driven architecture. Whether you go all-in on event sourcing or just adopt a simple pub-sub model, the mapping is clear. You've already defined the key events, commands, and views. Just follow the model.
It also helps you to properly decouple and isolate domains within a complex system. Explicitly define how events flow across boundaries. Apply patterns like CQRS to separate writes from reads. Track your KPIs and navigate the bottlenecks. Identify opportunities for autonomy and innovation. Again, it's all there in the model.
But perhaps most importantly, Event Modeling puts people at the center. It's a collaborative design tool that brings together business and tech, research and development, to build a common shared understanding. It's the foundation for domain-driven design – and the foundation is your model.
And finally, Event Modeling is not a silver bullet; rather, it is a mindset that saves money by enabling a shorter and more precise development cycle!
So there you have it, folks – the inside scoop on Event Modeling. This isn't your grandma's waterfall – this can be a real game-changer for your career or if applicable for your own business.
But don't just take my word for it. Dive in and give it a try! Grab some sticky notes, gather your team, and start mapping out those events. As I always say it's not just about the destination, it's about the journey.
And who knows – you might just have an epiphany like I did: "Suddenly, it was so simple all along, but everybody just refused to see it!"
Until next time, happy event modeling!
🔎 Explore more: