infoShare '18 flashback: Event storming. It doesn’t make much sense to write great code… to a wrong process

It doesn’t make much sense to write great code… to a wrong process. If we start work without really understanding what is going on inside the organisation, we might be heading for a disaster. It will take ages till we get the software right (if ever), even with best IT-minds on board. 

25.09.2018, added by InfoShare

As Sławek Sobotka (Bottega IT Minds) says:  “The guys writing code often don’t understand the problems the software is meaning to solve”. And that’s where event storming comes in. 

Designed by Alberto Bartolini, event storming is a flexible workshop format for collaborative exploration of complex business domains. The workshop is easy to organise, takes a few hours and lets us dig really deep into what really happens on operational levels. 
There’s two goals of an event storming session. A strategic one – which uncovers the business process and an operational one – which helps identify the main rules that govern it. 

What do you need for an event storming session? 

A room, lots of sticky notes (in different colours), a paper roll, something to write and… the right people. You should invite the domain experts – company managers, directors on the one hand, and technical staff - those who will be writing code on the other. For the second group, it’s important to get people who are experts at designing practical models, those who really know how software works and what can be done. Another additional person is a facilitator, somebody who keeps track of the rules and makes sure the work flows smoothly. The goal of the session is to identify the process, the sequence of events and conditions which must be met for an event to happen. 

What does it look like?

To cut a long story short: First write out all domain events – or what happened in business (this should be a verb in the past tense for every event). Then ask why did this event happen and look if it is connected to any other event. Find for each domain event the command that caused it - commands connect the events. Identify the commands, write them down and put on your model using a different colour of your sticky notes.  
That’s when first “islands” appear that will later form the structure of you software. It’s a foundation for all the work to come.  
Sobotka’s company, Bottega IT, frequently uses event storming so he readily shares some practical advice how to use this technique. If you want to make things right, there’s a few tips and tricks to follow. The most important ones are: 

  • Make sure writing is easy to read and you have enough space for all the events. 
  • Always be standing. Remove all chairs and don’t allow the people to sit. 
  • Don’t think about your structure or database in advance, they will form naturally later on.
  • Remember that commands are not GUI interactions.
  • Remember that a domain event is what really happened in business, not GUI. 
  • Respect that some people (about 10%) are not compatible with this technique. They have a different way of thinking and you must accept that. 
  • This technique will quickly show ignorance of any business process. Should this happen let the manager keep face. 
  • Collect all the wrong decisions. 

If you’re interested in using event storming to design a system that is clean and easily maintainable, check out Sławek’s second presentation where he dives deeper into technical details.



See also:




Contact the editorial team at: