
EventStorming: Continuous discovery beyond software modelling - baasie
https://xebia.com/blog/eventstorming-continuous-discovery-beyond-software-modelling/
======
the_duke
> EventStorming ... is ... a flexible workshop format for collaborative
> exploration of complex business domains. EventStorming is a technique that
> uses visualisation to minimises assumptions by engaging in deliberate,
> collaborative learning between different disciplines. EventStorming helps to
> solve complex business problems in the most effective way beyond silos or
> specialised boundaries.

So, deciphering this BuzzwordStorming: you get together and model your
business domains in a group, using visual aids.

Quite revolutionary! _cough_

~~~
wpietri
I know you're being sarcastic, and I agree that marketingspeak is, as always,
annoying.

But I do think this is revolutionary. The typical processes people use for
understanding a novel business domain take weeks to months. That's when they
use them at all; most places just make shit up, write it into the software,
and then experience a lot of pain when it is slowly discovered that the model
expressed in the code doesn't really match the domain.

Traditional processes for understanding the domain also tend to focus on
nouns. That's understandable, as a lot of what we build (UIs, objects, API
results, identifiers, database tables) are about nouns. But starting there can
be hard, especially for novice users; they _use_ an implicit domain model and
domain language, but they have rarely thought about it, so prying it out of
them can be half anthropology, half philosophy.

But events are something people understand better, as everybody knows how to
tell stories. And over the last decade we've seen the rise in event-driven
approaches to system design. Focusing on events can of course solve a lot of
problems in distributed systems. But things like React also show how thinking
about events and data flows help even at very small scales.

So I look forward to trying this out next time I have a new complex business
domain to model. It looks faster, easier, and more fun. I'd then probably
combine it with something like Patton's Story Mapping to figure out what needs
to get built:

[http://www.jpattonassociates.com/the-new-
backlog/](http://www.jpattonassociates.com/the-new-backlog/)

~~~
dragonwriter
> Traditional processes for understanding the domain also tend to focus on
> nouns.

The most traditional requirements development and system analysis process I
can think of, structured analysis (as developed by Ed Yourdon at others and
first popularized in, IIRC, the 1970s), focuses on modelling a planned
response system in terms of the events it needs to respond to and what it
needs to do in response, and decomposing it into subsystems modelled the same
way.

Using shared visual models is a common technique when applying Structured
Analysis, too.

~~~
wpietri
Good point. Perhaps instead of "traditional" I should have used a different
word. Here I'm referring not to documented formal processes (which I almost
never see used in the wild) but to what I have seen, which mainly seem to be
folk wisdom. So tradition in that sense.

As I said, I think a lot of this folk tradition arises out of the practical
needs of developers. They are asked to build a hazy thing; in trying to figure
out what that thing is it's easy to reach for concrete representations, like
business forms and database tables. And of the class structure in object-
oriented languages, which is obviously noun-focused.

I suspect another source of difference between what I see used and most formal
processes is that the most formal processes tend to come out of a waterfall
tradition. There's a stop-the-world-for-months aspect to them that I think is
incompatible with a lot of what people do today. Certainly with the dynamic
world of startups, but also with the short-cycle processes that modern tools
enable for everybody.

I could totally see using Event Storming and Story Mapping as two one-day
activities as part of a kickoff week for a new project. Structured analysis,
not so much.

~~~
dragonwriter
> I suspect another source of difference between what I see used and most
> formal processes is that the most formal processes tend to come out of a
> waterfall tradition. There's a stop-the-world-for-months aspect to them that
> I think is incompatible with a lot of what people do today.

It's true that a lot of formal methods were first defined then. Those that
weren't abandoned entirely were refined beyond that time, though; you might
find Yourdon’s last (before throwing it to a Wiki which was somewhat
unsuccessful and vandalized) documentation of the Structured Analysis method,
his freely-available PDF _Just Enough Structured Analysis_ from 2006,
illuminating. [0] There's no stop the world aspect (except in one of the two
polar extremes of approaches to application, both of which are described as
impractical for real projects.)

> I could totally see using Event Storming and Story Mapping as two one-day
> activities as part of a kickoff week for a new project. Structured analysis,
> not so much.

It's true that Structure Analysis is a full-lifecycle activity, not a kickoff
event; OTOH, there are certainly parts that map out the problem space that
work as kick off events.

[0] [http://zimmer.csufresno.edu/~sasanr/Teaching-
Material/SAD/JE...](http://zimmer.csufresno.edu/~sasanr/Teaching-
Material/SAD/JESA.pdf)

~~~
wpietri
Is there some specific part of that 600-page book would I find illuminating?
From the intro, this is clearly a phasist approach, so essentially waterfall.
E.g.:

"Regardless of its name, it becomes the input to the person (or people) who
are responsible for actually building the system — that is, designing the
overall architecture of computer hardware and software and ultimately writing
and testing the computer programs. This leads us to Part IV: life after
systems analysis. We will explore the transition from systems analysis to
systems design and briefly discuss the final details of programming and
testing."

I'm sure there are people out there whose domains are stable enough that they
can work like that. But fewer and fewer. And I suspect even the ones who can
would be better working in a much more iterative, exploratory way.

~~~
dragonwriter
> Is there some specific part of that 600-page book would I find illuminating?

The part most directly relevant to the point at which I raised it is Sec. 5.5,
beginning on p. 91.

~~~
wpietri
I see what you're saying, although I'm not sure it's really moving in a
direction I'd call agile. He clearly paints the fully "radical" end as
unthinkable lunacy, when it's entirely doable in practice. And looking at
figure 5.4, it's very much a document-oriented process. When compared with a
modern, short-cycle Agile approach (continuous delivery, unit-of-work size in
the 1-3 day range) all of the documentation he describes ends up being pure
waste.

This part strikes me as especially absurd:

"How does a project manager decide whether to adopt a radical or conservative
approach? Basically, there is no right answer; the decision is usually based
on the following factors:

* How fickle is the user?

* What pressure is the project team under to produce immediate, tangible results?

* What pressure is the project manager under to produce an accurate schedule, budget, and estimate of people and other resources?

* What are the dangers of making a major technical blunder?"

The contempt for users wrapped up in "fickle" is ridiculous, and ditto making
business needs about "pressure". Most importantly, he hasn't even begun to
recognize that a shorter cycle yields significant business benefits, even
though that was being written about at least a half-dozen years before this
book.

So I read this more as typical waterfall thinking with some concessions to
practical reality (which is how waterfall has always been done) than anything
relating to a modern approach. He doesn't say, "You must stop the world for
100% of your project!" But the fastest he's willing to describe is, "Stop the
world for 50% of your project!" The notion that you could stop the world for
1% or less of your project (which is what happens with weekly cycles for a
project of 2 years or more) is to him beyond ultra-radical. (Let alone a good
kanban approach, where the cycle time drops into the hours-to-days range.)
When instead I'd submit it's in reality the most conservative approach, in
that it minimizes all sorts of risks.

------
kornakiewicz
I recommend this book n which this method is described and explained. Also F#.

[https://pragprog.com/book/swdddf/domain-modeling-made-
functi...](https://pragprog.com/book/swdddf/domain-modeling-made-functional)

~~~
mrdoops
I'm especially fond of his description of boundaries and the trade-offs of
different kinds of contracts between bounded contexts. There's also a lot of
good insight into how we abuse the database and couple ourselves to it for the
convenience of CRUD. Really feel like I should've picked up this book months
ago.

~~~
dvlsg
It's always refreshing to see a writer that's honest about trade-offs, instead
of spouting their preferred method as the one-true-way which will solve all
your problems.

------
weego
Process as a way of getting conference gigs.

