Event storming: Domain distillation under steroids

Last friday, I organized an event storming session at work (one of the major investment bank in France). It was my first time as an organizer and I must admit that I've been truly impressed by the efficiency of this way to distill a domain.

Created by Alberto BRANDOLINI, Event storming is a fast way to explore a business domain or problem with many people in the room -including non-IT stakeholders. In a nutshell: you put every domain experts in the same room with few ITs and you make them describing what happen or must happen in their Business. To do so, you make everyone naming and positioning domain events (stickies here) on a large time-line-oriented-paper on the wall.

"What do you mean by 'Domain Event'?" is probably the first question you'll face as an event storming organizer. To quote Mathias VERRAES (another DDD expert and event storming practitioner), a domain event is

"Something that has happened in the past that is of interest to the business"

We are NOT talking about IT details here, like applications, databases or any button click... (unless its part of your core domain like for Google or other ad-resellers). That's why I stated at the very beginning of our session: "Let's forbid us to speak IT or technical things for the couple of hours to come. Business only!".

"It's developer's understanding, not your knowledge that becomes software!"

"What will be the outcome of our session?" is another legitimate question from the audience when it's the first time. In our case, the objectives were:

1.  To share a common understanding of core business concepts and what to do within our project.
   
   The project I'm talking about is an ambitious greenfield IS reconstruction for an entire business line. The fact that we have to deal with all functions -front to back- is a real challenge. Indeed, there are many bounded contexts and teams involved in our case. Everyone coming from various functional and technical backgrounds. As a Domain-Driven-Design (DDD) practitioner, I was recently worried by the fact that we were talking a lot about technical data formats (mediums/vehicules) or ambiguous concepts during workshops, and less about the core business concepts in stake. Fortunately we have lots of expertise here, tons of talented BAs & IT specialists. But to quote Alberto when he faces recalcitrant domain experts: "It's developer's understanding, not your knowledge that becomes software". In other words: it was time for non-domain-experts like me of few other developers to catch-up with the others.
   
   
2. To Fight vagueness and to clarify various ambiguous concepts faced during our previous workshops. The outcome here would be to initiate a 'lexicon' for our project, taking care about the scope of the definitions (by indicating the bounded context to which a definition applies for instance).
   
   For non DDD practitioners: a Bounded Context is a context within which a model applies (e.g.: marketing, negotiation, settlement, etc.).  Although it is important for a model & language to be consistent within a given context, we can perfectly have the same word indicating completely different concepts - or most likely - different perspectives on the same core concept depending on the context or usage we are talking about. Working without those contexts in mind could be really misleading. Moreover, sharing the language of our business (a per bounded context exercise) is also the starting point to have what we call in DDD an Ubiquitous Language (i.e.: to always rely on the language of the business -including within our code). As benefits, we avoid misunderstanding and "translation" issues, but we are also able to have efficient discussions with the business all along.

By the way, I forgot to tell you that there were no people from the business within our event storming. We were 11 people in the room including tons of domain experts in various contexts; profiles such as Business Analysts (mainly), domain-expert-IT-managers, and some developers/tech leads & a use-case-driven architect ;-)

Modus operandi

First thing's first: the preparation. Discovered in 2013 during a DDD meetup in Paris with Mathias VERRAS, I've since read and watch lot of things about event storming. Nonetheless, the fact that I was quite noob in this field made me asked tons of questions before our real session at work. And I'd like here to thank my friend Tomasz JASKULA (co-organizer of the Paris DDD meetup) but also Mathias, Alberto and Emilien PECOUL for their time and availability when I asked questions on Twitter few hours before my session.

Our event storming was schedule between 2PM and 4PM this Friday. In term of logistic I finally decided to go to the mall aside at lunch, in order to buy a roll of garden tablecloth to make what Alberto calls the "unlimited modeling space" on the wall.

Yes, Roberto warn me few hours before on Twitter: "make sure that location, stickies availability and space aren't constraining the discussion." So I also came with a bag full of working markers and tons of stickies.

source: Event Storming recipes (A.BRANDOLINI)

Before pinning my tablecloth on the wall, I moved out all the chairs in a dead-end corner of the room so that:

• people remain active during the workshop
  
  and
• to be able to observe the body language of all the attendees (much more complicated when they are seated as stated by Alberto).

Indeed. Like when we are playing poker (I confess ;-), it's very important to observe low signals, body languages and tells that betray possible disagreements among people (whether it's due to introversion or political agendas). As said earlier on the phone by Tomasz, "one of the objective of event storming is to identify possible disagreements on how we understand our domain". Either to settle them on the fly, or to park them for after (during another session for instance).

Once the room ready, people started to join me. It took me less than 8 minutes to explain the rules and the objective of this event storming to the eleven attendees before we put our first stickies on the wall.

There are many kind of stickies and possible approaches for an event storming (I let you read the "Event stormers" google plus group or Alberto and Mathias' blogs for further information). But this friday, we focused on "Domain Events" only (not the Commands, the Aggregates or the Actors). Thus, we almost only use "orange" stickies with past-tense sentence on it (e.g.: "Price Requested", "Order Executed", etc.).

source: Event Storming recipes (A.BRANDOLINI)

After one hour and a half, we wrapped up our session by identifying all the core concept of our domains (reading what we wrote on our stickies to do so), and started to collectively gave definitions for few of them on the left side of the tablecloth.

Takeaways from this first experience

• Used to Reactive Programming or CQRS architectures since various years from now I am pretty comfortable with the notion of event ;-) But I was pretty impressed that everybody followed the "Use past-tense sentence" rule (on Domain Events stickies). It sounded really a natural way for everybody to tell our business story.
• It seemed important to clarify from the beginning that we weren't here to produce another new official model/artifact for the project but to interact instead. Indeed, we were here to be on the same page and to collectively explore ambiguous part of our Domain. I had the feeling that it helped some of us to relax and not to fall into model perfectionism.
• It was hard for some of the attendees to avoid talking about IT things, applications, existing systems (even from Business Analysts). Nonetheless, we collectively succeeded to stick to our initial objective ("Business only!")
• Disagreements about some core concepts (e.g.: trade done vs. order executed) were quickly resolved with the support of all participants in the room able to add views and precisions (including naive questions from the non-experts). Visually also, with the support of other related Domain Events all around.
• It's been hard for some of us to realize that things that are currently done by existing IT systems correspond to real (Business) Domain Events (e.g.: the trading portfolio routing/attribution)
• Some people (4/11) started to take back some chairs and to sit. I hesitated to ask them to stand up like the others but after few minutes of observation, I realized that they were still actively contributing, answering to questions from the others. At the end of the day, I had the feeling that they needed somehow this background position to be able to see the big picture on the wall.
• We had few sub-groups during the session (distilling a subpart of the wall in parallel during few minutes here and there), but almost everyone actively followed the overall business story. Before the session, I feared some kind of post-it contention on the wall with 11 people (and disengagement as consequence) but nothing like that happened. Event Storming is really a fluent way of working together. It's amazing the efficient bandwidth we had to discuss and get in-sync with multiple people.
  
  
• As stated by Emilien PECOUL on Twitter, it is important to let people do their things and to not constrain them too much: "Let paralell discussion emerged". Nonetheless, I found interesting to make few "attention call to everyone" when we had to decide an important point or to answer a key question.
• To quote Alberto BRANDOLINI: "it is KEY that location, stickies availability and space aren't constraining the discussion". After this first Event Storming session at work, I can't agree more. The space or lack of space is really impacting the discussion. BTW during the session, I had to pin another piece of paper on the right while everyone was busy on my left, dangerously close to the end of the tablecloth ;-)
• Fortunately, I'd read Mathias' "Facilitating Event Storming" blog post before organizing this session: "Know when to step back. Don’t do the modelling, guide the modelling. Ask questions". It allowed me not to intervene too much in the modelling as the organizer of this Event Storming session. In a nutshell, I just tried to ask questions, to rephrase or to identify blur zones or implicits concepts.
• As for any other workshop, it was crucial to ensure a benevolent atmosphere so that everyone feels comfortable and willing to contribute in public. We joked here and there during this 2 hours sessions, but it was really a positive co-construction mindset.
• I waited almost one hour before suggesting the group to trace bounded contexts on the wall (between the stickies). In my opinion: if done too early, there is a risk to constrain the space and thus, the discussion.

To conclude on this first Event Storming experience at work, I would say that I've been truly impressed by the efficiency of this dispositive.

I would recommend it for any business domain exploration

For this first experience at work we focused only on the Domain Events (i.e. the "Orange" stickies). It probably eased the ramp-up for everyone in the room. But I'm very keen now to retry an Event Storming with the other tools such as querying the Domain Events causality (i.e. identifying Commands, People or External Systems), but also by identifying clearly the Aggregates involved (Stickies with other colors).

But as I said on Twitter just after this session:

Stickies are just a pretext for high bandwidth discussions & ultra efficient domain distillation.

And for that, Event Storming is an awesome tool.