OUR THOUGHTSTechnology
Event modeling: A socio-technical approach to system design
Posted by Arjan Noordhoek, Gareth Evans . Aug 29.24
Event modeling is a software design and development approach introduced by Adam Dymitruk. It’s a method for designing and building systems based on capturing and modeling the events that occur within a business domain.
The approach balances intentional architecture with emergent design by modeling state changes through the journey of a product or system.
Core concepts
At its core, event modeling is about capturing and mapping out the key events that occur within a process or domain. However, the approach puts a strong emphasis on outcomes and value creation. It should help answer the questions of “why are we doing this?” and “what is the end result we want?”. Focusing on outcomes helps align the modeling process with real business and customer value.
As Dr. Russell Ackoff famously stated, “A system is more than the sum of its parts, it’s a product of their interactions”. Event modeling focuses on these interactions, shifting our attention from solutions to business outcomes. Some interactions create value, while others merely pass information through. Pass-through interactions can indicate inefficiencies, suggesting that data is in the wrong place and needs to move closer to where interactions can add value. Event modeling takes a socio-technical approach to design by focusing on the interactions between humans and technology over time in the form of events.
Dymitruk describes the approach as “modeling, over time, a system’s state changes caused by events.” Event modeling is a visual representation of interactions between systems and the resulting system state changes required to deliver a measurable outcome.
Key principles
Event modeling is guided by several core principles and concepts. First and foremost is the outcome focus, which ensures that all events and processes are tied back to desired business outcomes and value creation. Context mapping is another important principle, grouping events into contexts to create clear boundaries and promote loose coupling between different parts of the system.
The use of ubiquitous language is emphasised, ensuring consistent terminology across the model that aligns with business language, helping to create a shared understanding. Developing a ubiquitous language improves communication between technical and non-technical stakeholders, reducing confusion and rework. Event modeling prioritises scenarios over implementation details like user interface design, focusing on business logic and rules rather than premature solution design.
The concept of slices is central to event modeling, breaking the model into implementable pieces that deliver incremental value. Finally, event modeling leverages common patterns like commands, events and queries to structure the model, providing a consistent framework for implementation.
The event modeling process
Setting goals
The process begins by defining clear goals and outcomes. For example, a supermarket might have a high-level goal of improving customer loyalty. This could translate into an Objective and Key Result (OKR) of improving the home delivery service. Key results might include increasing the number of repeat orders from the same customer.
Identifying context
The next step is to identify the context in which the modeling will take place. This involves looking at the business activities that should be involved in achieving the mission. For our supermarket example, we might focus on the context of external orders for home delivery.
Mapping events
Once the context is established, we start modeling the interactions required to reach the key results. We identify all the different activities needed for home delivery and map them out as a series of events along a timeline. It's important to keep identifying who owns the responsibility for each outcome as this can reveal potential inefficiencies in the process.
Implementing the timeline
To implement the modelled timeline, event modeling introduces three key patterns:
The Interface Pattern: The Interface Pattern starts with the events from the timeline, including the facts. It’s an iterative process to include and update facts. The interface pattern represents the input coming from a screen, API or other source that results in an action (command) which allows us to apply an event. When not all input is directly available, the pattern can be extended with queries that provide the missing details.
The To-Do or Automation Pattern: The Automation Pattern, also known as the ‘To-Do Pattern’, is a state machine that listens to events it’s interested in. It subscribes to a starting event (or multiple events), creates an initial state and then updates its state based on subsequent events. When it reaches a complete state according to its business rules, it calls a command and then may subscribe to a resulting end event of that command.
The View Pattern: The View Pattern subscribes to one or more events from one or more process steps to deliver a read model. The read model can then be accessed through a UI or API. This pattern aligns closely with the concept of projections in Command Query Responsibility Segregation (CQRS).
The following shows how the three patterns connect with each other:
Benefits of event modeling
Event modeling offers several key benefits. It improves business alignment by expressing the model in business terms, enhancing communication between technical and non-technical stakeholders. The approach is flexible and technology-agnostic, allowing the model to evolve independently of implementation details.
Mapping events and their relationships helps identify gaps and dependencies, leading to more complete system designs. Each slice of functionality is discrete and testable, improving overall system quality. The event-driven nature of the approach enables systems to scale with high throughput.
Implementing event-driven systems
When implementing systems based on event models, several key considerations come into play. Event sourcing, which involves storing all state changes as an immutable log of events, is often used. Capturing all state changes as events in an event log provides a complete audit trail. The event log also allows for ‘time travel’, enabling the reconstruction of past states of the system for analysis, compliance or debugging purposes.
Command Query Responsibility Segregation (CQRS) is frequently employed to separate read and write models, improving scalability and flexibility.
Bounded contexts are implemented as separate services with clear interfaces, promoting modularity. Event-driven messaging, using message buses or streams, is used to propagate events throughout the system.
Challenges and considerations
While event modeling offers many benefits, it’s important to be aware of potential challenges. There’s often a learning curve associated with adopting event modeling, especially for teams used to thinking in terms of data models or user interfaces. It requires a shift in thinking towards events and state changes.
Dealing with eventual consistency in read models can be challenging for developers accustomed to synchronous systems. It requires careful consideration of how to handle scenarios where data may not be immediately up-to-date.
As systems evolve, handling changes to event schemas over time becomes important. Techniques like event upcasting may be used to translate old event formats to new schemas, ensuring backward compatibility.
While individual patterns in event modeling are simple, managing many fine-grained events and processes can introduce complexity. Proper tooling and practices are essential to keep this complexity manageable as systems grow.
Event modeling offers a powerful approach for designing systems around business value and outcomes. By focusing on the key events in a process, it creates alignment between stakeholders and supports building flexible, scalable architectures. While it requires new skills, event modeling can dramatically improve communication and accelerate the development of complex systems.
More Ideas
our thoughts
Unpacking the SCARF Model
Posted by John Stephenson . Oct 03.24
Have you ever found yourself or your colleagues reacting strongly to certain situations at work, seemingly out of nowhere? Maybe it was a change in job title, a shift in responsibilities or feeling left out of a meeting. John Stephenson unpacks the SCARF Model, a framework for motivating and understanding such behaviour...
> Readour thoughts
Unlocking the power of flow metrics
Posted by Steven Gibson . Sep 26.24
Our product landscape has become increasingly customer-centric. With the speed of market disruptors, organisations are constantly seeking ways to improve their ability to deliver value to customers and to pivot and respond. One powerful tool that has gained traction in recent years is the use of flow metrics. However, unlocking the power of flow metrics requires a holistic approach that goes beyond just measuring single team performance. In this article, we’ll explore the challenges and offer some guidance for leveraging flow metrics to optimise your entire value stream.
> Readour thoughts
Improving flow with layered test automation
Posted by Gareth Evans . Sep 19.24
The ability to deliver high-quality code quickly and consistently is paramount. Two concepts that have revolutionised our approach to this challenge are the Test Automation Pyramid and the principles of flow and feedback. In this blog, Gareth Evans explores how these ideas intersect and how adopting the Test Automation Pyramid can significantly enhance your development flow and feedback loops.
> Readour thoughts
Value is a flow
Posted by The HYPR Team . Sep 08.24
The HYPR team came together at their latest WorkerBee event and discussed why ‘building the right thing’ can’t be separated from ‘building the thing right’...
> Readour thoughts
Part 1 – Using OKRs to drive strategic growth
Posted by Martin Kearns . Sep 02.24
In part one, Martin Kearns takes lessons from the track and looks at how using OKRs drives strategic growth, as well as leveraging short-term milestones to test assumptions and stay on track.
> Read