Improve business process with Event Storming

A sample use case for improving business processes with Event Storming and a simple guide to facilitating your Event Storming workshops.

Why Event Storming?

Earlier learning about business systems meant mapping the business processes through technical modelling approaches or using trial and error to write the code as you build a solution. Due to the technical nature of these models, many domain experts are left out of the conversation. Developers are not the only people thinking about software development, your company's business team, your customers are also thinking about software development. To transform domain knowledge into business software use Event Storming.

What is Event Storming?

Event Storming is created by Alberto Brandolini, and it is a workshop for exploring business domains. Event Storming includes multiple levels of stakeholders in the business and drives greater understanding and productivity by simplifying the approach. It is a visual and interactive process that encourages team members to collaborate and share their knowledge to uncover domain events and identify business rules.

How does Event Storming Process works?

Let's dive into the event storming process. We are going to take a sample use case and run through all the event storming steps to understand the process.

Our sample use case is about reconciling financial statements from two businesses. In our sample use case we have one entity as Company and another entity as Vendor. Both entities have their financial statements with a list of transactions between them. Our intended system receives statements from both entities, processes the statement data and reconciles the same. Below is a simple illustration of our use case.

Step 1 - Event discovery

This is the first phase of event storming. We (everyone in the event storming session) write down all the events as a sticky note on the evat board. We treat this phase more of brainstorming rather than any analysis. We focus on quantity rather than quality. There may arise three scenarios.

• Someone may write a proper event for example an event may not be associated with core business, we can park such events as hotspot events

• Someone may not come up with any event as he or she may be a new member and may not know the business in detail, we can ask then for educated guesses

• There could be many discussions during event discovery which may go off-topic, however we should try to focus on the core business - the very reason for which the business is started

For our Reconciliation system, we came up with below events. At this point we have just discovered the events. We tried to name the events in such a way that is meaningful to the domain experts and business stakeholders.

Step 2 - Organise and Structure Events

Our ultimate goal is to come up with a consistent narrative of the business processes of our business. We will achieve this by placing the event on a horizontal timeline in the proper order.

One way to organise the events is to start with a starting event that kicks off the whole process. Another way is to identify pivotal events. Pivotal events are critical events for the business process and they create other events.  

In our use case we identified the starting events where a company user configures a new reconciliation which generates other events. We have organised them on a business process timeline (business process start and end). 

There may be some other events occurring in our business at the same time for example "New vendor added" or "New reconciliation rule added" and we can create another business process timeline for the same as shown in the below diagram.

Step 3 - Business Process Event Storming

We now have identified our main business process (the lifeline of our business), in our use case the main business process is reconciliation of two statements. 

Its time to identify missing pieces in our business process.. We do this by using a technique called “reverse narrative” where we try to describe the main business process starting at the end,  telling the story backwards. With this we identify all the missing events.

In addition to the events, there are other elements in a business process and the business process will be incomplete without these elements. Once we have identified all the events in our business process, we add these other elements such as Actors, Commands, Policy, External System to make the business process complete. By doing this we understand the roles and responsibilities of the various system components.

Commands (blue): These are requests to do something. They can originate from a user or system or another event. In our example, it would be ”Configure new reconciliation”, “Send vendor notifications” and “Send company notifications” etc.

System (pink): These represent systems involved in the domain. They may issue commands or receive commands along with triggering events. In our example, we have also identified an external system as “Notification System” which is external to our business process and we have shown the same in the below diagram.

User (yellow): These are human users involved in the process. They may be a single person or a department/team. We have company users and vendor users as our users and we have identified them in the our example and we have shown the same in the below diagram.

In our example, we can see that the command “Configure new reconciliation” and the event “New reconciliation configured” are the same. This is an indication that we have not described the business process in detail. We need to describe the additional details of the business process which result in new events. 

This is the right time to introduce business rules of our business process for example, in our sample use case a reconciliation period and notification template are required. This introduces a new element “Policy” in our event storming. Policies represent standards or business rules that may need to be executed. 

We also add another element “Read Model (green)” to represent the data that may be critical for a user or system to make a decision. To truly define a command, we need to understand the data that is needed for the command to produce the event.

With the addition of other elements, we now have our business process with all the required elements. Business flow naturally emerged when we connected the elements, binding them together to represent a cohesive business process that follows proper commands and leads to expected outcomes within certain boundaries.

So in our use case, we start with configuring a new reconciliation which is followed by receipt and processing of company and vendor statement which leads to reconciliation execution. We have our business process depicted with proper commands leading to expected outcomes.

Step 4 - Define the business context

During the structuring, we can see the emerging core domain and the subdomains. Core domain is the function that drives your business and subdomains are the functions that support the cor domain.

In our example use case, our core domain is reconciliation execution and rest other activities are considered as part of sub domains.

For example, we have grouped together commands, events, and events that deal with configuring a reconciliation which is a subdomain supporting our core domain. Similarly statement validation and statement process are subdomains that handle the uploaded statements and supports our core domain which is reconciliation execution because without data we can not execute reconciliation.

Statement validation and statement process are subdomains that handle the uploaded statements.

And finally there is a reconciliation execution our core domain, that reconciles the data and generates a report.

Step 5 — Putting it All Together

Now we have completed the business process level event storming steps. The biggest achievement of business process level event storming is to achieve a clear landscape of business problems that we need to solve. In the event discovery, we looked at “Why the system exists”. In the business process event storming, we looked at “What the system is doing”. With the Event Storming outputs (core domain, subdomains with commands, policies, data model), the engineering team gained strong ownership of the context and a shared business language to delve deeper into the technical definitions.

We can now start with design level event storming to detail “How a system will solve the business problem”. The design level event storming is normally done by a technical team where the architecture and design is detailed.

To Conclude

Learning about the system by writing code is a very expensive way of understanding business processes, instead use event storming which includes multiple levels of stakeholders in the business and drives greater understanding and productivity by simplifying the approach.

Event storming has emerged to be a great way to align business stakeholders and engineering teams in taking the best design decisions for the product.

Event storming can be used in different scenarios:

• To discover the most effective areas for improvements in your business.

• To explore the viability of a new startup business model;

• To envision new services, that maximise positive outcomes to every party involved;

• To design clean and maintainable Event-Driven software, to support rapidly evolving businesses.