3 Ways Event Storming Helps Build Enterprise Software
In the last few months my organization has made move towards describing our problem space using Domain Driven Design. We build enterprise software that powers Microsoft's global computer networking services. In this space we use a hybrid of vendor appliances and homegrown software solution to provide a better service to the users of our network.
We've recently gone through several event storming sessions to have a better understanding of the product we're delivering. The goal of these sessions is to produce a diagram that looks something like what you see below.
There are lots of great tutorials and introductions to event storming, so I won't waste much time describing it here. I want to share what I've learned facilitating these sessions over the last few weeks. Below are the 3 most valuable things things that I've taken away from these sessions.
1. Common Understanding of The Problem Space
When we were initially designing this product (which helps us configure network devices like Cisco routers and switches) there was A LOT of back and forth between the network engineers and software engineers. The network engineers are the subject matter experts who understand the domain, and the software engineers are responsible for delivering the systems that can improve the reliability and speed while also reducing human touch points.
There were weeks of discussion about how this flow would work, and we had to create and re-create these diagrams as new things came to light. In short: we started solving technical problems before understanding the business problems.
The great thing about event storming sessions, is you specify 1 story you're looking to map out from start to finish. Instead of modeling what the software does, you map out all of the "domain events" that make up an entire workflow. Instead of diving into the technologies, you just consider the events themselves. What are the automated processes? What are the manual processes? What things trigger certain events? All of these get mapped out before you even think about what type of database or API framework you're going to build.
The rules also encourage no more than 8 people in a session and having good representation from the business (PMs), domain experts (SMEs), and leaders from the delivery team. The goal is to create a document that everyone, irrespective of discipline, should be able to understand and interact with.
It's incredibly powerful to have everyone involved in the creation of these diagrams because when you break people out of the silos, and you try to understand the bigger picture new things pop up. In our sessions, we identified multiple processes that I had no clue that took place in the background! Bringing everyone together, and working on this shared mental model of the problem really helps uncover potential areas of improvement and new capabilities to add to your systems!
2. Model Manual Processes Alongside Automated Processes
If your company has been throwing around the term "digital transformation" it's likely that your new software ventures are either replacing work that was done by hand or with a legacy tool, and replacing it with something a little more modern.
In our space, there are a lot of activities that network engineers do by hand (scheduling change windows, sending out change notifications, etc.) that our software engineers wouldn't know about because we don't perform those tasks. So when we start to decompose a workflow we define a reasonable starting/stopping point, and try to explore all of the relevant activities that happen within that timeline.
For example, if a network engineer needs to interact with one system to create a change ticket and another to send out communications to a team, we try and capture all of those interactions. Then, after we identify the entire flow we can find pieces of the flow that we might be able to automate using software! Things that we hadn't even thought of in the beginning.
If you're building a tool for a Small to Medium Sized company, it might not be financially feasible to automate every piece of your business. That's okay! As you work through your event storming sessions everyone will leave with a common understanding of how the business works; and you can take that information and come up with a roadmap to automate the things that can reasonably be automated!
3. Reduce Engineering Churn on Unknown Workflows
How many times have you seen an engineering team start writing code for a project that didn't have a clear vision? Almost all of my projects have started out like that. Luckily, through hours and hours of discussion eventually something usable shakes out.
What I've found with using these event storming sessions, we're able to identify new features that we can add to the product without wasting time trying to develop Proof of Concepts to prove the thing works. We map out the data necessary to power the workflow, what the user interactions will look like, and even what the error scenarios are like. All of this happens with the business and subject matter experts in the room. Complexities are explored and documented as a team, and there's no magic-wand-waving when it comes to how these workflows bring value to customers.
We're able to start engineering design discussions with some initial artifacts, and can produce more technical visuals based on the initial event storming diagrams. Plus, if you're using a digital white board/sticky note tool; you can update these flows as time goes on! Then, as you build up the muscle as a team and organization in hosting these sessions, the event storming methodology just becomes another tool in your toolset to quickly iterate on new features and deliver value to your customers.