About Me

My photo
Rohit is an investor, startup advisor and an Application Modernization Scale Specialist working at Google.

Saturday, August 10, 2019

Event Storming - A Pivotal Practice for decomposing applications

Name of method

What is this method ?
Event Storming is a cross functional facilitation technique for
revealing the bounded contexts, microservices, vertical Slices,
trouble spots and starting points for a system or business process.

Discovery, Kick Off
Suggested Time
1 - 2 hours. 
Who participates?
SMEs, Core Team (see facilitator notes)
Why do it?

Event Storming enables decomposing monoliths into microservices.
It allows for modeling new flows and ideas, synthesizing  knowledge
and facilitating active group participation without conflict to time travel
and ideate the next generation of a software system. 
When to do it?
When you need to make sense of a Huge mess to enable Cross
Perspective Communication as a force function for clarity.
What supplies
are needed?

People, tools and supplies needed to conduct an ES session
  1. A large wall (for stickies)
  2. At least 4 different colored stickies
  3. Sharpies
  4. Blue painters tape
  5. Refreshments  like water and soda and juices for hydration
  6. Paper flip boards for readouts and breakouts
How to Use this Method

Event Storming is a group exercise to scientifically explore the
domains and problem areas of a monolithic application.
The most concise description of the process of event storming
comes from Vaughn Vernon's DDD-Distilled book and the color
around the process comes from Alberto Brandolini's book
Event Storming.

Storm the business process by creating a series of Domain events
on sticky notes. The most popular color to use for domain events is
orange. The DomainEvent is a verb stated in past tense and
represent a state transition in the domain. Write the name of the
DomainEvent on an orange sticky note. Place the sticky notes on
your modeling surface in time order from left to right. As you go
through the storming session, you will find trouble spots in your
existing business process. Clearly mark these with a purple/red
stick notes. Use vertical space to represent parallel processing.

After all the events are posted experts will post locally ordered
sequence of events and enforce a timeline. Enforcing a timeline
triggers long awaited conversations and eventually STRUCTURE
will emerge. 

These event clumps or common groupings give us our notional
service candidates (actors or aggregates depending on how rigid
the team is with DDD definitions).  These will be used during the
Boris Exercise.

“You know you are done when…”
- Event Storming generates an immense backlog of user stories.
- Perform  User Story Mapping to Map and organize stories into MVPs
- Define scope of the problem
- Confirm that you are solving the right problem ?

Facilitator Notes & Tips

Event Storming is a technique used to visualize complex systems
and processes. This could range from monoliths to value streams.
Event Storming is gamestorming technique for harnessing and
capturing the information captured in a group’s minds. It surfaces
conflicts and different perspectives of a complex system and bubbles
up the top constraints and problem spots.   As an event storming
facilitator you have one job - create a safe environment for the
exchange and output of ideas and data. The job is 50% technical
facilitation and 50% soft people facilitation where you are reading
body language. A single facilitator can typically orchestrate groups
of 15-20. For a group of 30 or more you need two facilitators. 

ES is usually conducted in two phases. A high level event storm to
identify the domains and then a subsequent ES into a top constraint -
the core domain. The language of ES is stickies. In its simplest form
ES is basically a facilitated group story telling. The stickies represent
domain events -  or things that happened in the past.
The trouble spots are identified by orange/red stickies.
The color of the stickies does not matter. What does matter is that you
start simple and then add the notation incrementally. Start simple and then
add the information in layers. ES can serve many goals - break down a monolith into constituent bounded contexts, create a value stream - as a
way to onboard employees, etc., There is no ONE correct style of ES. Every
session is different from another based on the desired goals and outcomes. So
don’t worry about getting it right- just do it and roll your own style.

An ES is only successful if the right people are involved. This is a
mix of business domain experts, customer executives, stakeholders,
business analysts, software developers, architects, testers, and folks
who support the product in production. Subject matter experts,
product owners and developers that knows and understand the
application domain. This process enables cross perspective
conversation throughout the team as well as a standard definition
of the terms used by both technical and non-technical team members.
Related practices

Real world example 
Recommended reading
Motivation behind ES can be found here -
Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers.

Note this book is available on safari books online:
This is the book we read on the flight to Boston Eventstorming

Book is written by Alberto Brandolini the father and inventor of Eventstorming

Domain Driven Design (DDD) - provides the theoretical underpinnings of decomposing
 ‘/monoliths. DDD Distilled is the perfect book to understand the science of DDD and
how ES fits into the grander scheme of things - how do the ES artifacts translate into
 software design, architecture and an actual backlog.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.