EventStorming is a set of workshops created by Alberto Brandolini, which aims to discover a set of domain events, each represented as a colored sticky (usually orange) and ordered along a timeline. The fundamentals of this practice are also described in Alberto Brandolini's book Introducing Event Storming. 

In the article  Remote EventStorming Brandolini describes three flavours of workshop

  • Big Picture
  • Process Modelling
  • Software Design

This article is a facilitator’s guide for gathering requirements during a Process Modelling workshop, based on Brandolini’s Remote EventStorming workshop, as well as my own experiences. The guide assumes some knowledge of EventStorming and the Big Picture workshop. To get a higher level view of the different EventStorming workshops and when you can use them, you might want to read my blog EventStorming - What's it all about?

My aim with this guide is to bring some rules and a structured method to the modelling exercise. It does not cover the entire workshop but focuses more on what you will need and how you can go about modelling a process.

By the end of the guide you should have an understanding of:

  • Who to invite
  • Who should facilitate
  • How to set up a working environment
  • Prepare a board for modelling, after a Big Picture workshop
  • How to use EventStorming grammar; Event, Policy, Actor, Action, Read Model, Bounded Context
  • How to build a model by layering grammar, over multiple narrations
  • How to capture language
  • What you should expect from a successful workshop

EventStorming Process Modelling Workshop

The EventStorming Process Modelling Workshop works best discovering high level processes with state driven workflows that can be orchestrated with events. Its notation and grammar is designed to highlight communication between domains and model behaviour across systems.

Process modelling with Big Picture EventStorming has the aim of adding layers of notation in the form of different colored stickies, also referred to as grammar, to capture more information and validate assumptions.

Alberto Brandolini suggests it is like making a pizza, where events and a timeline give you a margarita, but you can add more grammar to make different pizzas. Though he did warn that you might be tempted to put grammar that isn't suited for EventStorming, such as data tables. He likens this to pineapple, and insists it should never be on your pizza.

In this guide I will stick to the grammar described in the book and in his workshop.

What you will need

  • Large wall space or digital collaboration space such as [Miro](https://miro.com/)
  • A bounded area labelled Preconditions to the far left of the board
  • Sticky notes of 6 different colours and 2 legends
  • If using a physical board; black, red and green markers

Prerequisites

Previously you should have run a Big Picture exercise and prioritised a process to model

  1. Participants have organised stickies between domain events in a timeline.
  2. A single process has been nominated for modelling
  3. A copy or snapshot of the main storming board has been taken.

In brief, the scenario prioritised is the purchase of an adventure, by an explorer, through an agency. For the purposes of this exercise I shall reduce the scope of modelling to just purchasing and payments, indicated by the event Adventure Accepted.

When modelling a process with pains, opportunities and questions, adding these to your process modelling board can start to create clutter and noise before you have even begun. 

I will often leave a 1:1 copy with stickies, pains, opportunities and questions taken from the main storming board at the top for reference and then start anew, copying only the stickies that are necessary to begin modelling the process. In the examples used here I have completely avoided pains and opportunities and questions, to allow for a cleaner representation.

In our example we will use a scoped process that involves the payment of an Adventure. The primary actors are the Sales Assistant, Customer and Cashier. For this process there are at least 2 domains, customer service and sales ordering. We would expect domain experts to have been identified in the Big Picture workshop and invited to this.

Participants

When considering the 3 pillars of software development, as described in User Centred Design: Domain experts represent the Business Viability, Designers represent the User Desirability and an Architect/Engineer would represent Technical Feasibility. It is important to have these three roles to maintain a balanced discussion and transfer of knowledge.

The minimum number of participants should be 3; one narrator, one scribe and one audience. Although you can run these workshops with larger groups, there may be advantages in breaking down the process and scheduling multiple workshops, inviting only the experts that have an interest in the scope of what you are modelling. If there is contention or contradiction in language or process, ensure both sides are present in order to gain ubiquity.

Facilitators

Facilitators often vary depending on availability, however I would prefer facilitators to represent the three pillars of UCD; business, user and technical, within a software development team. For example a product owner, a designer and an engineer might assume these roles and facilitate the workshop to ensure a balanced discussion and keep the workshop relevant to all participants.

The Rules

Roles of the mob:

There are typically 3 roles:

  • A Narrator reads through the process from left to right.
  • The Audience listens to the narrator and assists in discovering the process.
  • A Scribe records the process on the board.

Any participant can take on any of these roles. Encourage participants to change roles, so everyone develops both ownership of the process and a deeper familiarity with the exercise.

Narration

The method described below uses separate narrations to layer more grammar at each stage, with the main goal of getting through the process with the grammar you have got and then move to the next narration to add more detail, until you have a complete process.

On each narration read through the stickies on the board, describing the process from left to right. The primary goal is to start from an entry point into the system and validate the scenario until you have reached the optimal outcome, or have agreed that to go further would go beyond the scope of your project. You will still want to capture events on either side of your scope to keep track of inputs and outputs as preconditions and postconditions.

Notation:

The model uses a notation, where different coloured stickies representing a set of grammar are used to describe steps in the process.

I would describe a single step in a process as:

An automated or manual decision, supported by one or more read models, to execute one of many actions, which raise one or more events. 

In Brandolinis' book the stickies for each step are grouped and referred to as a Policy. This implies to me the decision is key to the step and so I use a policy name to label it.

Lines are drawn between grammar to denote a flow between steps, as well as within a step. There would always be a line that links an event to a policy, and this would represent moving from one step to another. Using the layout that I am now accustomed to, I only use lines within a step to indicate which events are raised by an action as I find adding other lines is unnecessary and just creates noise.

Brandolini attempts to be light on grammar rules as I think he would like to be flexible and offer people the opportunity to decide for themselves how best to use the notation. I however have identified some good rules that I believe help in reducing complexity and keep the model clean and readable.



 Events: Represent a state change or notification that another part of the system wants to react upon.

Events can be raised as a result of an Action or raised automatically as a Timed Event.

  • An Event can be raised by many Actions.
  • An Event can be listened to by many Policies.
  • Events used in preconditions are assumed to be timed or modelled elsewhere and do not need additional grammar.
  • Timed Events do not have Policies or Actions.
  • Timed Events should be identified with a symbol or tag on the Event sticky.

 Policies: Represent a decision to perform a task. Sometimes this is written as a short sentence or can be labelled and described somewhere else.

Policies can be manually performed by an Actor or automated by an IT system.

  • A Policy listens to a single Event.
  • A Policy should call one Action per decision outcome.
  • Multiple Policies can call the same Action.
  • A Policy description should include the Event they are listening to, a decision to be made and at least one Action to take.
  • A manual Policy should have a single actor associated.
  • An automated Policy should not have an actor.
  • If a policy can both be automated and manual, these should be treated as separate policies.

 Actors: Represent a person responsible for making a decision and performing an action.

  • Only one actor should be associated to a policy
  • If there are two roles in a business that can fulfil the same policy, assume they are "wearing the same hat" and choose an appropriate role to represent that hat. 

 Actions: Represent a task that must be performed due to policy, and produces one or more events. Actions are also referred to as Commands.

  • An Action can raise multiple Events.
  • If an Action raises more than one event, these should be placed in a column, with the event that triggers the next policy at the top.
  • Multiple Actions can raise the same Event.

 

 Read Models: Represent data required to make decisions or perform Actions.

Read Models should be small chunks of relevant structures or fields.

  • Multiple Read Models can be assigned to a Policy.
  • Read Models can be used by multiple Policies.

A Note on Systems: Brandolini uses systems during his workshops to identify tooling, however I have deliberately left this out as technically it is not needed to capture a process. It might be useful to capture Systems in the Big Picture workshop as they are discussed, however I feel it is best to avoid modelling Systems until after you have a process that is agnostic of tooling. For the purposes of this article I left systems out and will cover them in another article. 

Happy Path

Often you will want to start with a happy (aka golden) path. This is a scenario where everything goes smoothly and no failures or issues arise. In the model it can be defined by a set of preconditions and the quickest path to a post-condition.

If you have prioritised pain points, you should try and ensure you find that path flows through one of these pain points. This may not always be the happy path, as you might have identified an edge case. However I would still recommend getting the golden path first and then moving onto the appropriate edge case

New Processes

While the main goal is to follow the process chosen from the main storming board, you might discover new processes, or identify entry points to already discovered processes. These can be separated and moved to another board, with the relevant event acting as a pre-condition.

Questions

If an assumption is being made or there is no way to clarify parts of the process with the people in the room, leave a question on the board and return to it later with the right people or new information.

Pains and Opportunities

If new pains or opportunities are identified then add them to the board as you would in a Big Picture workshop. 

The Method

  1. Arrange the process modelling board
  2. Narrate Happy Path Events
  3. Narrate Policies
  4. Add Read Models and Label Policies and Bounded Contexts
  5. Narrate Additional Paths

In my examples I use a sample process that I modelled as part of an investigation into using EventStorming to tell a children's story. The scenario is simple and is loosely based on a popular story, the Lion and the Mouse.

1. Arrange the process modelling board

When you are ready to start modelling a process, domain events from the bigger picture should be copied and brought into the modelling board and arranged in the following way:

Preconditions: Identify events which need to have happened before this process can begin and put them in a bounded area on the left, under the title Preconditions.

Post-conditions: Identify at least one suitable event which describes the optimal outcome of the process.

Arrange any remaining events in chronological order from left to right between the preconditions and postconditions.

In this example we have chosen to reduce our scope to Adventure Accepted, so all previous events become part of the precondition. This leaves Payment Authorised and Payment Rejected as known domain events, and Explorer Left Shop and Commission Paid become our post conditions

We have also identified a change in domain language, as Explorer becomes Customer during the context of this process. We also Identified that the agent would have to be busy at this point, as they are serving the customer.

At this point we could capture the language for:

  • Shop: A location from which agents sell adventures
  • Adventure: A package tour
  • Customer: A buyer of adventures
  • Agent: A seller of adventures on behalf of a larger company
  • Payment: Monies or the promise of monies taken for the purchase of an adventure
  • Commission: Monies given to the agent for the completion of a purchase


2. Narrate Happy Path Events

Usually the main goal of the first narration is to make best efforts at identifying domain events along the happy path.

Start by reading through the storming board stickies from left to right, using the language from each sticky to identify suitable domain objects that can act as a state change. An object undergoing a state change becomes your domain event.

Domain experts should provide clarity on naming and describe complexities in the process.


Using the yellow stickies and the help of domain experts, we discover that there is a process of getting from an accepted adventure to two types of order, a purchase order and a sales order. 

The agent starts the transaction by submitting a purchase order, the cashier creates a sales order, which is then confirmed and paid for by the customer.

Getting confirmation of payment from the cashier with a receipt, marks the end of the transaction for the customer and a successful payment marks the end of the purchase for the agent

Discovering this kind of information is a good sign you are ready to move into modelling policies. 

We could now capture the language for:

  • Cashier: A person who handles the sale of an adventure and takes payment
  • Purchase Order: A list of goods or services, with associated costs and quotes, provided by a customer or agent to a tour operator when purchasing an adventure
    • Create: Created by a customer or agent when terms of the adventure have been agreed.
    • Complete: A Purchase Order is complete when details of the Sales Order payment have been captured
  • Sales Order: An order created by the cashier on behalf of the tour operator, detailing the adventure being purchased and associated costs
    • Create: Created by the tour operator when a purchase order is created
    • Confirm: Before taking payment an order must be confirmed by the customer
  • Payment Request: A request from the cashier for immediate payment
  • Card Payment: A credit card transactions being made through a third party payment system
    • Created: Created when credit card details are used to make payment through a third party system
    • Authorised: The third party system will authorise a payment when payment details are correct and there is sufficient credit
    • Rejected: The third party system will reject a payment when payment details are not correct or there is insufficient credit
  • Receipt: A description of payments for a given sales order, provided by the tour operator as proof of payment.
    • Issue: A receipt can be issued when payment has been authorised


3. Narrate Policies

The goal of this narration is to understand the decision and actor behind each event. This will help validate your events and identify missing steps.

From left to right, go through the events and start to identify the decisions that led to that event being raised. Decisions being made by a person should be given actor stickies.

A policy should be written as a statement with the following format: Given <event> happens I should <actions>. 

If you have identified good domain events, usually the decision being made will be quite obvious and the action derived directly from the event itself. To help validate your policy and event, I recommend finding at least one alternative action that could be taken as a result of the decision.


In our example the Agent makes the decision to create a purchase order or upsell. Creating the purchase order would move the customer into a process of purchasing and paying for their adventure.

The next two decisions were fairly easy. The Purchase order has to be accepted for a Sales Order to be created and the customer should confirm the sales order for a payment to be requested.

At the beginning the Purchase Order can be rejected and at each stage after that the sales order or payment can be cancelled.

When the sales order is confirmed the cashier needs to decide how to proceed with collecting payment and the customer needs to decide what form of payment to use. Identifying the choice on payment options also influenced the renaming of the domain event, and the understanding that a receipt is created by the 3rd party system led to a new event.

The payment is made via a third party system, which will authorise payment and create a receipt or reject the payment. The cashier can issue the receipt and the customer can leave but also the agent can complete the purchase order so commission can be paid. Understanding that a receipt is created by the 3rd party system led to a new event, which was listened to by the cashier who could then issue the receipt.

New language discovered: 

  • Up-sale: An opportunity to sell more goods or services
  • Purchase Order:
    • Rejected: A purchase order can be rejected by a cashier or tour operator if there is insufficient detail in the purchase order, or the tour operator cannot fulfil the adventure
  • Sales Order
    • Cancelled: A Sales Order can be cancelled at any time during the process
  • Receipt
    • Created: A receipt is created by the third party payments system
    • Cancelled: A receipt can be cancelled and not issued to the customer
  • Customer Follow Up: Before completing a Purchase Order it may be necessary to follow up with the customer first.
  • Commission
    • Revenue: This is a form of commission that can be given to all agents
    • Gross: This is a form of commission that can be given to partnered agents


4. Add Read Models, Label Policies and Identify Bounded Contexts

The next narration is to finalise the policies with names and read models and identify bounded contexts. 

Policy naming can follow a simple convention of Resolve <previous event>, however for readability you can be flexible on this. 

Read models represent data that would be needed to assist the user or system in making a decision. Try not to be too granular, identify groups of data that might come from a single source.

Bounded Contexts are usually derived from the exchange of data across subdomains, marked by pivotal events where the status change of one object triggers a new actor or system to make a decision.

Names represent the context in which things are happening. Often it relates directly to divisions within the business as these contexts are already understood by the domain experts. They will usually derive from an adjective that is consistently used throughout the naming of abstract domain objects, such as order, to give them a specific context.

In our example we have named all our steps, added read models to all policies and identified pivotal events, by reducing the size of non-pivotal events.

We have also identified 2 domains; Customer Service and Sales. Sales is fairly obvious as we are primarily working with a sales order, however the purchase order does not come from a context called purchasing as that means something else in the business and so we look at other objects that might change status. We can use our domain experts to identify that for an agent to be busy they must have started a customer service engagement and introduce a new precondition Customer Service Engagement Started. We can also add in the events for Agent Available and Customer Service Engagement Ended, to get an understanding of how these other processes close off.  Finally we have a new adjective Customer Service that seems to work well as a context from which our process starts and ends. 

Identified by the change of language from Purchase Order to Sales Order and the change in roles from Agent to Cashier we can nominate Purchase Order Created to be a pivotal event and thus marks the boundary between Customer Service and Sales. 

Payments and Receipts can exist elsewhere in a system but under different contexts mean different things. This leads us to the conclusion that both Payment and Receipt are part of the context of Sales for this model.

Finally we return to the Purchase Order marking the end of the Sales context and a return to the Customer Service Context where we end our engagement with Customer Service Engagement Ended and Commission Paid. We also have Shop and Commission, both of which could have different meanings under different contexts, and so conclude these should be modelled under the context of Customer Services.

We also identify that the customer sits in two contexts and so we need a definition for each.

New language:

  • Customer Service: The context in which an agent works with a customer to identify a suitable adventure and price
    • Customer: A prospective buyer of adventures
  • Sales
    • Customer: A buyer of adventures
  • Payment Plan: The way in which payments will be taken
  • Payment Method: Ways to pay immediately: Cash, Card, Bank Transfer etc.
  • Payment Details: Customer details, used to perform immediate payments


5. Narrate Additional Paths

Once you have a completed happy path and cleaned up your board, you can now model alternative paths with relative ease.

Often you can start by identifying any remaining domain events from the Big Picture workshop and model these. Alternatively you could start from left to right and model additional actions already identified in previous narrations.

The principles remain the same, first identify your events, then policies and actions, then read models and naming. 

When you are modelling a looping behaviour it should always be represented as a loop between steps. One step ends with an event which is listened to by a policy. By treating the policy and all its actions and events as a single step, and giving it a name, we can easily model this behaviour without it getting too messy.

In our example we start modelling from an event discovered in the Big Picture workshop, Payment Rejected. 

This is simply a case of the customer deciding to make payment using some other means, or rejecting the payment request. The next step is a loop back to Resolve New Card Payment, where the payment can be authorised again

Review Questions, Pain Points and Opportunities

Try to reserve time to clean up the board a little, by addressing outstanding questions and consolidating unanswered questions, pain points and opportunities.

  • Simplify questions and remove duplicates
  • Try to answer as many questions as possible
  • If questions remain unanswered, schedule a short workshop to try and address them.
  • Ensure all pain points have been recorded and correlated to a sticky in the process
  • Ensure all opportunities are recorded and correlated to a pain point
  • Simplify descriptions of pain points and opportunities and remove duplicates

Success/Expected Outcomes

Capture information to assist further in the development process:

  • Define Ubiquitous Language: A common language that cuts through assumption and clarifies a shared understanding. A glossary can also be maintained to capture important language that needs describing.
  • Identify Domain Events: Domain Events describe communication between domain objects. They are raised by one and listened to by another, decoupling the dependency between them.
  • Identify Policies for Decision Making: Company policies describe business level decisions and relate them to users and data.
  • Identify Service Contracts: Events, read models and actions act as contracts between applications.

Discuss Pain Points + Opportunities: An understanding of where problems are experienced and ideas of how they can be resolved.

Identify scope: Try to identify a simplified end-to-end process that can provide the most value. This will be your starting point for design.

Discovery of opportunities:

  • The algorithmic model and use of Policies, can identify improvements in the process or user workflows
  • Policies are often where you identify the potential for automation
  • Read Models can identify opportunities to improve a decision making task

System Development Decision Making: Process Modelling artefacts act as evidence of requirements and priorities. The model can be used to describe scope and behaviour, while pains and opportunities identify value and priorities. This can be used to facilitate decision making and validate with stakeholders, work being undertaken.

That's It!

Here is what we have looked at:

  • What and who you would need to run an EventStorming Process Modelling workshop
  • What EventStorming grammar we can use and some basic rules to apply
  • How to setup your board and move from a Big Picture workshop to Process Modelling
  • How to build a happy path with 3 narrations
  • How to identify bounded contexts
  • How to extend the model to discover other scenarios

Hopefully this guide has provided some insight into my prefered method of modelling a process and can be useful to other facilitators and EventStorming practitioners. I have seen many challenges in facilitating EventStorming, and in particular Process Modelling. My hope is that by simplifying and giving some structure to the modelling exercise, there can be a unified method for facilitators to allow for more discussion about the problem and keep all participants engaged.

Please continue reading for some quick tips and come back to my blog in the future for more EventStorming and SDLC articles. 

Thanks and good luck.

Notes & Tips

Ubiquitous Language:

Naming can be contentious and often disagreements can be hard to settle. It is important not to spend too much time discussing names, and to use questions to allow for a less than perfect settlement to keep the conversation going.

Events

Finding suitable events is important to getting a good model

When discovering new events, do not apply strict rules on how events should be formed. Allow wordy descriptions that can be used to break down the grammar.

When discovering new events, do not apply strict rules on the nature of events. Allow for non-domain events to be highlighted and discussed, it is always possible to filter. 

Identify the important state change by understanding the object, action and who might listen to it. Write the event to make the object that changed state, the subject of the event.

For example, the "Agent wrote a purchase order". In this sentence the object Purchase Order is more important and a change in its state will be listened to by other parts of the system. The initial state is Created so we write it as "Purchase Order Created"

Passive-Aggressive Events

Filter or aggregate events that represent "Passive-Aggressive Commands" as described in Martin Fowler's blog What do you mean by “Event-Driven”?. These are often found when describing low-level workflows or the object raising state changes is a listener to that event. One way to handle this could be to squash all policies, actions and events into a new policy and action, written to describe the whole workflow. Identify which events are listened to and what negative events might be raised as a result of any failures from the squashed actions, again only if they are listened to by another domain object.

Policies

Writing Policies can be important to ensure you have an accurate process, and have captured the correct business requirement. Policies should be written as a decision that guides an actor or system to the correct action.

If there are two roles in a business that can fulfil the same policy, assume they are "wearing the same hat" and choose an appropriate role to be the actor

The actor may be responsible for implementing the policy but is rarely responsible for defining the policy. When discovering Policies, it is always helpful to identify Policy Makers, domain experts responsible for defining business policy that influences decisions. This can be done either by adding a sticky to each policy to identify a title and role of a domain expert, or create a separate area on the board where you can add additional detail to policies.

If good Roles are identified in the Event Storming stage then you should be able to identify roles that influence the decision.

Bounded Contexts

When naming bounded contexts try to identify abstract objects and then identify adjectives used to describe that object, within a specific context. E.g. Order is an abstract object, we put Sales in front of it to give it context, Engagement is an abstract object and we use Customer Service to give it context.

You might also identify a 3rd party or external system as its own bounded context. Quite often there is an established domain language and this may conflict with your own. However this is not always necessary for the purposes of identifying processes and could be left to software design workshops.

Recommended Resources

Alberto Brandolini - Introducing Event Storming

Alberto Brandolini - 50,000 Orange Stickies and Counting

Alberto Brandolini - 100,000 Orange Stickies Later

Remote Event Storming

What do you mean by “Event-Driven”?

DDD Crew Starter modelling Process