EventStorming is a technique that minimizes assumptions by doing deliberate, collaborative learning with different disciplines in order to solve business problems in the most effective way. We can use this tool in a variety of contexts - from deliberate discovery to team flow and from sprint retrospectives to detangling systems and from domain-driven design to designing CQRS/event sourcing systems and determining candidate microservices. As long as there's a story to tell and a timeline involved, EventStorming is a useful tool. In this blog, I'll dive deeper into how you can apply EventStorming for continuous discovery.
Moving toward a microservices architecture
We see many companies are moving toward a microservice architecture. The big pitfall of microservices architecture is to focus on the technology, how big the microservice needs to be, how many lines of codes, what entities do we put in a microservice, and using the rest as the communication between them. But to succeed, we need to focus on the problem space, by crunching domain knowledge and applying domain modeling. EventStorming is a perfect fit for domain modeling, and almost all the microservices leaders seem to agree. Even ThoughtWorks finally put it on 'adopt' in their most recent rendition of their technology radar. But to be successful and create autonomous teams, you need to use EventStorming for more than only Domain Modeling.
Event Storming or EventStorming
My first EventStorming experience was back in 2014 with Mathias Verraes in his Domain-Driven Design workshop. Since then I started to model my software with EventStorming. EventStorming, or mostly being written as Event Storming nowadays, is according to Alberto Brandolini his website a flexible workshop format for collaborative exploration of complex business domains. It's a technique that uses visualization to minimize assumptions by engaging in deliberate, collaborative learning between different disciplines. EventStorming helps to solve complex business problems in the most effective way beyond silos or specialized boundaries. Essential to EventStorming is creating the required space to model, meaning finding a wall at least 6 meters long to put a paper on. We need enough moving space, so that means in most meeting rooms moving tables and chairs to the side (especially at corporates). Invite the right people who have the knowledge needed (your domain experts) and give them a marker each. We focus on visual storytelling by writing domain events, things that happened, on an orange sticky and placing it on a timeline. It doesn't have to be orange, but it has to be consistent. Use a legend to make this explicit.
Conquer and Divide in EventStorming
The first part of EventStorming, the storming of domain events, is essential. Everyone has their perception of reality; everyone has their specific model in their mind. What we try to achieve is to let people make that model explicit with domain events. That means that a heuristic start is to let everyone write down domain events for their perception and place it on the timeline. Conquer and Divide is this pattern Alberto wrote about in his book EventStorming on Leanpub. There are many more of these patterns written down in that book. The book also describes three types of EventStorming: Software Modeling, Process Modeling, and Big Picture. To make used systems that in an 'as-is' process explicit, we use Process Modeling. A good starting point when you want to disentangle your current monolith or a big ball of mud system toward a more microservices architecture.
The blind man and an elephant
In my opinion, the most critical and exciting EventStorming type is the big picture. Especially in a Big Picture, conquer and divide is essential. You invite 20+ people from all silos in the organization to 'eventstorm' together. You need at least an excellent facilitator and an observer to pull this off, but it will help to battle the parable of the blind men and an elephant, where every silo thinks they have the absolute truth. A Big Picture EventStorm gives an organization a clear vision of the company goals and makes bottlenecks and competing goals explicit. It also starts showing you multiple contexts to create a context map of the organization. If you try to move towards more autonomous teams with a microservices architecture, Big Picture EventStorming will help your teams to share knowledge, align their goals, and focus on a shared vision.
Beyond Big Picture, Process Modeling and Software Modeling
As you see we need to do more than only EventStorming for Software Modeling. To create autonomous teams using a microservice architecture, we need continuous deliberate, collaborative learning to be successful. We need to move from Big Picture EventStorming, finding the context and bottlenecks, toward EventStorming Process Modeling. A process model will give you all the details needed to start finding the bounded context to move toward EventStorming Software Modeling. You can use EventStorming for more than only these three types. In a previous post, I already showed how I successfully used EventStorming to plan my wedding. Also, I use EventStorming a lot to model the development flow of the team as described by Paul Rayner in his talk 'Fighting the invisible enemy'. You can use it to map out your customer journey, value stream mapping, threat modeling, ethnographic research, post-mortems, and even for retrospectives. For everything with a timeline, telling a story EventStorming is my preferred tool. But don't think EventStorming is the silver bullet, it has its blindspot. I usually start with EventStorming and try to combine it with for instance Example Mapping, Domain Story Telling, Impact Mapping, User Story Mapping, and Heuristics Mapping. It all comes down to continuous, deliberate collaborative discovery with a visual tool. This post was also published on my personal blog site.
A lot of knowledge is lost when designing and building software — lost because of hand-overs in a telephone game, confusing communication by not having a shared language, discussing complexity without visualisation and by not leveraging the full potential and wisdom of the diversity of the people. That lost knowledge while creating software impacts the sustainability, quality and value of the software product. Kenny Baas-Schwegler is a strategic software delivery consultant and software architect with a focus on socio-technical systems. He blends IT approaches like Domain-Driven Design and Continuous Delivery and facilitates change with Deep Democracy by using visual and collaborative modelling practices like Eventstorming, Wardley mapping, context mapping and many more. Kenny empowers and collaboratively enables organisations, teams and groups of people in designing, architecting and building sustainable quality software products. One of Kenny's core principles is sharing knowledge. He does that by writing a blog on his website baasie.com and helping curate the Leanpub book visual collaboration tool. Besides writing, he also shares experience in the Domain-Driven Design community as an organiser of Virtual Domain-Driven Design (virtualddd.com) and Domain Driven Design Nederland. He enjoys being a public speaker by giving talks and hands-on workshops at conferences and meetups.