I've always adored EventStorming as a form of workshop - for many reasons:

  • the formula is all about direct, high-bandwidth collaboration with (domain) experts
  • it's very visual (as you're all standing in front of a white-board everyone can interact with)
  • it's based on a very simple (yet expressive) mental model (event as a key concept to describe reality)

But I also see some practical limitations. For instance, it truly shines only when you're knowledge mining - reverse engineering the existing implementation, processes, or ... domain dogmas.

What does it mean?

One should not treat the domain experts as an unquestioned source of truth:

  1. Obviously, they can be wrong, but (maybe even) more importantly, they may have their own bias (which they may be entirely sure about) that you'll creep into your solution.
  2. Part of the domain knowledge may be "how things were always done", "how everyone is doing that", or "how they taught us for decades to do it". But if you're building a new, innovative product, you may actually aim to build something better (faster/simpler/cheaper/...), more useful, and devoid of mistakes committed by the whole industry until now.

Marty Cagan has referred to that topic in his last book ("Transformed") as well. He emphasized the challenge of telling "domain knowledge" from "domain dogma". The borderline between these two may be a bit foggy, but essentially, "domain knowledge" is the inherent part of the domain that doesn't come from people's habits, quasi-temporal shortcuts (made permanent in time ...), or limitations we learned to cope with (& stopped questioning). The "domain dogma" is the rest :)

Needless to say, your goal is to make the most of the knowledge while ditching the whole dogma.

I also wrote a short piece on that some time ago (but definitely not as extensively or skillfully as Marty). In my article, I underlined the importance of the inquisitive mindset in analysts' work. A good analyst is not a chronicler who snapshots facts produced by someone else - there are specific critical thinking techniques (like 5xWhy or skilfully using open-ended and probing questions) that can help you to dig deeper and reveal the true knowledge behind the layers of dogma.

To conclude:

  • If your goal is not to capture the existing status quo but to create a solution, people will genuinely love ...
  • If you don't want to copy your predecessors/competition but outcompete them with innovation ...
  • If you'd prefer not to be limited by the fossilized beliefs of people who are too used to the current state of things ...

... instead of "canonical" EventStorming, you should reason from the first principles and work backward from the users'/customers' problems. Yes, that actually means it will be you putting the post-its on the wall, not the SMEs ...

There are no assumptions you shouldn't be questioning. Always triple-check if an axiom is truly an axiom (or a well-camouflaged piece of domain dogma). Master telling opinions from facts (that should always be based on real data), but also - learn spotting bias in data: how it is captured, measured, and interpreted. That may actually undermine many core foundations of EventStorming/DDD - even the ones about Ubiquitous Language ("always adopt the language of domain experts"; "as an engineer, don't try to fix UL", etc.).

What are the example questions you should start with (to work from the "first principles")?

  1. what are (the only) basic, undeniable facts about this problem?
  2. are there any particular scientific, mathematical, or logical principles that apply to this problem?
  3. out of the assumptions we have, can any be eliminated or replaced with more fundamental truths?
  4. if there's evidence supporting our assumptions - is it direct or indirect?
  5. can the problem we have be broken into smaller parts?
  6. have we properly defined the problem to be solved, and if we believe so - aren't there entirely different methods that we haven't even considered?
  7. the constraints that we have: what's their nature - are they based on technology, science, or just a way of thinking?
  8. given the fundamental principles you've just revealed, how would you design a completely new solution from the ground up?
  9. ... and could you resolve the problem in an even simpler way? with fewer steps or more limited resources?

Does this mean that one should not do EventStorming? Nope. The foundation it provides is very solid and easy to learn — feel free to adapt it to the mindset I've presented above, with no mercy to any dogmas that stand in your way.

Share this post