323: Building a Solid Business Model with Event Storming

Modeling information systems with event storming

Thank you for reading Snippets of Text. Snippets from media about tech, programming, parenting, and more. This is a preview of a post available exclusively to paying subscribers. You can get unlimited access to all articles by purchasing a subscription.

Thank you for checking out the free preview of Snippets of Text. Please consider subscribing to the paid version if you find my work helpful. This will allow me to dedicate more time to developing new ideas to share with you.

Breaking Down Silos and Improving Knowledge Sharing with Event Storming

Event Storming is a collaborative workshop that uses simple tools to model business processes with the primary goal of sharing knowledge effectively. The process starts by defining domain business events over a timeline. As the session progresses, new concepts such as commands, external systems, and actors are added to the model, improving its accuracy and comprehensiveness. Each Event Storming session has a defined scope that aims to explore a specific business process of interest to the group.

In traditional workshops, conversations happen sequentially, but with Event Storming, all discussions happen simultaneously. This way, any conflicts or discontinuities in any part of the domain can be sorted out, and everyone involved is present and engaged. Transparency is key to breaking down information silos and improving the accuracy of the model. 

It's important to note that event storming is an adaptable, valuable technique in both technical and business areas. Although this method can lead to a shared understanding of the domain by all team members, it's only sometimes guaranteed. Therefore, starting with behavioral modeling can be a good approach. Still, it might be necessary to break down behaviors into tasks and link them to processes. It's crucial to understand that these are implementation concepts, not business-domain concepts.

The biggest hindrance to DDD is developers' tendency to focus on what they understand well, such as software development concepts, rather than the business domain. One symptom can be seen when non-technical people, such as product owners or user advocates, come out of meetings with developers and begin describing the system using programming concepts rather than business terms.

[^1]: EventStorming Handbook

Building a Solid Business Model with Event Storming

The workshop starts with brainstorming domain events in a business process. Domain events have occurred in the business in the past and are represented by orange sticky notes. This stage aims to brainstorm all potential events in the business domain without worrying about their order of occurrence. Redundancy is acceptable.

I invite you to upgrade to a paid subscription. Paid subscribers have told me they have appreciated my thoughts & ideas in the past & would like to see more of them in the future.