EventStorming is the name given to a set of workshops created by Alberto Brandolini to facilitate gathering business requirements for the design and development of software systems.
This article is a high level overview of EventStorming with a brief dive into the workshops, what they are, when they could be useful and how artefacts can be useful throughout the development of software.
I highly recommend facilitators attend a course with Alberto Brandolini through Avanscoperta, and please check back here for future articles providing guides and tips based on my own experiences.
What EventStorming is trying to solve
Traditionally businesses would follow a System Development Life-Cycle; Planning, Analysis, Design, Prototyping, Developing, Testing, Integration, Implementation and Maintenance. Though other steps might exist, these are widely respected as core to the goal of delivering software systems.
Some key goals of planning are to define the problem space, identify the scope of existing systems, and determine the objectives of new ones.
Key goals of analysis include gathering details required for a new system as well as discovering opportunities and ideas for prototypes.
The planning and analysis stages can be laborious, requiring the coordination of many people. Often the problem space has evolved since the original system was designed. Systems become more complex and knowledge is lost or fragmented into opposing views and contradictory language.
Eric Evans coined the term Domain Driven Design, in his 2003 book of the same name as an approach to software design for complex systems. His method of domain modelling and collaboration between technical and domain experts attempts to address some of the problems around knowledge and language and facilitates a more top down approach to designing large systems.
Alberto Brandolini introduced the EventStorming workshops in 2013 in his book Introducing EventStorming as a lightweight method of modelling the problem space and facilitating collaboration between technical and domain experts, across multiple domains simultaneously.
The workshop uses story telling and a notation, described by Brandolini as grammar, to model algorithmic processes within an existing problem space. It can also be used as notation to support Domain Driven Design and Event Driven Architecture, as a proof of work.
What it’s not trying to solve
EventStorming, as described here, works best to discover high level processes with state driven workflows that can be orchestrated with events. Its notation is designed to highlight communication between domains. A pipeline or a sequential workflow, such as an authentication flow, might be too low level for EventStorming grammar to be useful.
Domain Driven Design favors Object Orientation and while EventStorming does lend itself to this, it does not dictate the paradigm adopted for the solution. It can identify where an object or module is used but ultimately, EventStorming is an algorithmic model of a process.
Domain Driven Design and EventStorming can be a good way of modelling requirements and maintaining a proof of work from a business perspective. While it can be used to discover actors and map user workflows against scenarios, further user research will be required so that their needs can be prioritised.
EventStorming in practice
EventStorming workshops have their place in any business with complex processes. It has the potential to act as a collaboration space for all domains, to validate a shared understanding of where problems lie and help drive software products towards the goals of the business.
However it is not the only route to good design. Approaches such as User Centered Design also have benefits and drawbacks. UCD, for instance, strives to find a balance between User, Business and Technical experts, but mostly drives a product from the users perspective.
From my experience it is possible to lead with EventStorming to identify scope, set context and capture language, business process, personas, scenarios and use cases. This information can be used to identify suitable opportunities to adopt additional methods, identifying specific needs and delivering a balanced product.
As an example, you might identify an important decision to accept or reject a sales proposal but to better understand what information is needed to make that decision, and how to best implement a tool to act upon the outcome of a decision might require additional investigation and a more user centric design workshop.
Photo by Dylan Gillis on Unsplash
The Workshops
The goal of an EventStorming workshop is to model a problem space by capturing one or more business processes. At its most primitive, processes are modelled through a set of domain events ordered along a timeline, however EventStorming can be run as a series of workshops, each building upon the previous workshops by including more detail and eventually capturing an algorithmic model of the problem space, and a notional system design.
The first in the series is called the Big Picture workshop and is considered the minimum level of detail to capture scenarios and processes in a short time with a large number of participants.
The workshop begins with a brainstorming exercise with domain and technical experts capturing a high level understanding of the business scenarios. The workshop then shifts into a mobbing exercise with narrator, scribe and an audience talking through and capturing processes as they are identified.
Brandolini describes two other workshops, one for process modeling and another for software design. These workshops are also mobbing sessions but focus on a subset of domains, with the aim of adding detail to each process, giving the model a more coherent structure and a notional design.
The Process Modelling workshop captures business and user decisions and the personas carrying out actions that come out of a decision. The model should also capture read models, actions, domain objects, bounded contexts, and validate domain events from the Big Picture workshop.
The Software Design workshop is intended to model existing systems, new systems and dependencies. Systems are identified by bounded contexts, containing domain objects. Dependencies are identified by user interaction, external systems and communication between aggregates.
Goals of EventStorming workshops:
- Model one or more business processes capturing domain events
- Detail steps in the process by adding, actors, policy makes, user decisions, business decisions, read models, actions and software systems
- Identify Policy Makers, domain experts responsible for defining business policy that influences decisions
- Capture key events where a process crosses domains and can be identified as state or event driven
- Capture domain objects and bounded contexts
- Align development teams with stakeholders and domain experts on language and business practice
Here are some additional goals you might want to aim for, while facilitating a workshop:
- Capture and prioritise pain points and opportunities
- Capture scenarios and use-cases
- Capture existing systems that currently support a process
- Compare process changes to validate hypotheses and product assumptions
EventStorming and Systems Development Life-Cycles
When to Run Workshops
Planning: To define the problem and scope of any existing systems, as well as determine the objectives for the new systems.
Analysis: To model workflows that make up processes within the organisation.
Design: To identify existing components and model new components and their behavior.
EventStorming can facilitate large groups in gathering the information for planning and analysis. All participants agree on the problem space and scope, while the model and notation capture processes, language and existing systems.
The model also acts as a visual aid for ongoing discussions between business and technical experts, to validate design assumptions and capture a notional architecture.
To be most effective, run EventStorming as early as possible to draw out assumptions and start looking for alignment and consensus between technical, business and users.
Big Picture
Ideally, this workshop is run with pre-determined domain and technical experts, prior to identifying the scope of an SDLC. I often use the workshop as an opportunity to cast the net wide and discover scope and opportunities with the most value. Big picture workshops typically take a couple of days, and can require the attention of many experts, depending on the complexity of the problem space.
Often it is not practical to analyse all processes with all experts present and so I have used Big Picture workshops to identify scenarios and make assumptions with the people available. Later we will use this to find experts that can validate assumptions and language in scheduled follow-up EventStorming workshops.
Sometimes, a fixed scope and prioritised objectives have been identified prior to technical experts getting involved. In this situation I have used a Big Picture workshop to discover scenarios and outlying processes, and to capture the impact of change to systems out of scope. This could be a much shorter workshop, involving fewer people with the aim of moving onto Process Modelling to validate assumptions and build confidence in the scope and opportunities we have been given.
The final outcome from a big picture workshop should include a set of discovered scenarios and related processes, which have been prioritised for further analysis. There are many techniques for prioritisation, which I will not cover in this article, however it is important to do this before moving forward, to ensure you are working efficiently and investigating the most valuable opportunities.
Process Modelling
A Process modelling Workshop can be run after a scenario has been selected during a Big Picture workshop. This workshop requires a minimum of 2 technical experts to fulfil the roles of narrator and scribe, and at least one domain expert.
Typically I have run these workshops immediately after the Big Picture workshop as the discussion is still fresh in people's minds, however it is possible to schedule these at times more convenient for the required participants.
Initial Process Modelling workshops are used to get a deeper understanding of the process as-is. However I have also used them to collaborate with domain experts to flesh out ideas and opportunities for change to processes and workflows. This could take place during design, or even development phases of the cycle.
Also during design and development phases, a closer inspection of existing systems can take place. This might result in opportunities, assumptions, language and even workflows being uncovered. A Process Modelling workshop is a great way to get business and technical experts in the same room to discuss and validate opportunities and assumptions, and the impact of newly discovered information.
After a successful Process Modelling workshop you should have a reliable representation of a process that is required by the business. You should also have achieved a ubiquitous language that everyone has agreed to, and identified sub domains and bounded contexts to assist in breaking down the problem space. You should also have identified actors and policy makers who will collaborate on the work going forward.
Software Design
Software Design workshops can be run after a process has been modelled, and requires technical experts to participate, though domain experts may be helpful to validate language and naming. The goal is to add detail to an existing process model, identifying existing and new systems and external dependencies.
When migrating a legacy monolithic system, for instance, I have used these workshops to map out where the legacy system is used to support individual steps in a process model. Then we suggest alternative solutions to each step in the process, using the Domain Driven Design concept of aggregates to decompose the monolith and map dependencies by identifying external systems required for each step.
By arranging stickies on a timeline, the model describes an algorithmic process, with a high level of abstraction. It is often preferred by technical experts to translate this algorithmic model into a paradigm such as Object Orientation. From my experience, it can be beneficial to do this during a software design workshop, in parallel with identifying existing or new systems and while narrating a modelled process. I have used tools such as context maps and C4 to capture this model along with dependencies and lower level abstractions so that the system is clear to the developers.
By the end of a Software Modelling workshop, you should have identified domain objects and their dependencies to other objects and external systems. You should have a notional system design that can be taken forward into other design workshops or a development phase. It might be possible to begin development phases from here, but I would recommend considering other design workshops to align with the user and ensure you are effectively addressing both business and user requirements.
Hieroglyphics on a temple wall at Karnak, Egypt. from Encyclopedia Britannica © uwimages/Fotolia
The Artefacts
All artefacts created during the workshops help to define stories and build a backlog of work. They are also used as a visual aid to design and development, communicating business requirements to technical experts. The language discovered should be reflected in both stories and code to maintain a visible trace from analysis to implementation.
The ideal practice is to gather all participants in a room with physical tools; white board or paper, stickies, and markers as humans are more efficient at sharing ideas and building alignment when co-located. A digital format offers unlimited space to identify core decisions and maintain a more easily-accessible history of change that acts as a great tool for proof of work.
The resulting grammar can become a template for Domain Driven Design, discovering Aggregates, Policies, Read Models, Actions and Events. The flow of the model naturally lends itself to Command Query Read Segregation, Event Sourcing and Event Driven architectures, should these be desired architectural patterns.
In addition to the modelling board and its grammar, the workshops act as a means to capture a glossary of terms and identify personas, scenarios and use-cases. These can be used to support other requirements gathering workshops.
Some uses for the artefacts
Discovery of opportunities:
- The algorithmic model and use of Policies can identify opportunities to improve either the process and/or the user journey
- Read Models can identify opportunities to improve a user or automated decision making process
- Actors and automated Policies identify the potential for opportunities through automation
Decision Making:
- All of these artefacts act as evidence of requirements and priorities. These can be used to re-enforce decisions and validate work to be undertaken
Setting Scope:
- The decomposition of an event storming board by workflow offers a first opportunity to define or refine the scope of work to be undertaken
- Prioritise processes by pain points and/or opportunities
- Use additional grammar such as Preconditions, and Policies to identify a first iteration
- Prioritise scenarios by value and complexity
Notional Architecture:
- Use additional grammar such as policies and commands to identify and correctly name domain objects and events
- Use the algorithmic process model to discover the notional architecture of existing software and external systems in the same way as a "north star" notional architecture is used
- Use additional grammar such as Policies, Actions and Read Models to define a notional architecture at the code level
- Use Preconditions, Actions, Read Models and Events to drive the discovery of how enters the system, and where it is used.
- Use Actors and automated Policies to identify synchronous and asynchronous operations
- Use Domain Objects and Bounded Contexts to suggest a notional microservice architecture
Story Writing:
- Use Actors to identify the target of user stories and define a persona for user research
- Use Policy Makers to identify the target of stories with business requirements.
- Use EventStorming grammar to define a story and it's value
- Use Policies to identify opportunities to improve either the process or the user journey
- Use Read Models to identify opportunities to improve a user or automated decision making process
The following diagram identifies some ways to use each piece of grammar
That's all folks
Hopefully this article has helped improve your understanding of EventStorming and it's usefulness for your own systems development methods.
I am presently writing further articles which dig deeper into each of the workshops and offer more guidance and tips for facilitators, so please come back soon to get more insight into my experiences with EventStorming and other SDLC topics.
Thanks and good luck
