EventStorming: Continuous discovery beyond software modelling
xebia.com
xebia.com
So, deciphering this BuzzwordStorming: you get together and model your business domains in a group, using visual aids.
Quite revolutionary! cough
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:
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.
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.
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...
"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.
The part most directly relevant to the point at which I raised it is Sec. 5.5, beginning on p. 91.
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.
"But I do think this is revolutionary. The typical processes people use for understanding a novel business domain take weeks to months."
You must be aware that there is a large group of people who have largely solved the problem of learning about a domain when client is in the room. It includes Business Analysts, System Analysts, some portion of people who call themselves Solution Architects, some portion of people who call themselves [software] consultants, and probably other roles, too.
There is nothing significantly new to ES. It's a specific method to run a workshop, with a client, live. It's one of many, many well known methods used in IT design/analysis. Not under this name though.
It's the same as half of Agile Industrial Complex (to quote on of Agile Manifesto's authors) -- people take a good technique and give it a name to market themselves or to promote the technique in the industry.
Don't fall for it.
"Traditional processes for understanding the domain also tend to focus on nouns."
I don't know where you get this from. What processes do you mean specifically? If you look at BABOK (Business Analyst body of knowledge, a good reference point), you will notice a huge section of _dozens_ of tools used to map and understand a domain and then to model a system for that domain... ES is just one item out of many, many methods.
Many of those methods have nothing to do with nouns, they are far more generic.
Sorry about the rant, but I was just sharing the same thoughts with a colleague who's learning some basic aspects of business/system analysis, so here goes...
The actual, real problems with running _any_ kind of joint work on requirements with clients are the REAL challenge of software dev teams in most models, and here's just a taste of what they can be:
1) client won't come to see us. Yes, seriously. 2) client will agree to a VC, but VC quality is so poor we have to go to them 3) we can go to the client, but we will never get 2-3 key stakeholders in the same room before project deadline. So we must do separate workshops, which complicates things. 4) Getting a team of people to another country for several workshops gets expensive fast. 5) Some members of the team don't want to or can't go
And now for the actual work...
6) Facilitation of a workshop such as this is generally a difficult job, one needs specialized skills to make it effective. ES proposes a format, which can be helpful, but to get value from a workshop you need good facilitators on the team AND a format, not just a good format. If you can have only one, pay for a facilitator, and let him pick any format, it's generally more useful. Formats are easy to get, and won't cover all the needs of a particular client-team relationship anyway. 7) Facilitation of a workshop is generally far beyond what a typical 25-30 year old software developer can handle given their typical focus (this specifically targets the myth spread by one optimistic ES promoter in my country who tells developers "just do ES workshop!" but fails to recognize the high level of soft skills required to make it effective, esp. with clients who don't have much time). 8) wrong people from the client have come, but you only realize it halfway through the workshop. Time wasted, potential misinformation spread 9) time required to collect all the necessary information this way is larger than total time you have to deliver something to the client to prove to them you are a good supplier of software. So you need results much sooner than this before they even let you work with them.
And finally...
10) People take time to ingest and process information. Lots of new information + many people = long time. It's not 1 day and we're done.
Summary: Just hire an analyst and your team will thank you. If your team is already good enough in terms of facilitation skills to run Event Storming, you don't need Event Storming.
The problem I mostly see is that each of this body of knowledge has their modelling tool, one where you need to have some form of workshop or certification (UML, Archimate, BPM etc etc..). What EventStorming tries to do is minimise these handover from proxy domain expert to avoid cognitive bias made from telephone games. So it tries in a simple and quick way to share knowledge in a multidisciplinary group and create a shared mental model, and do this continuous. It tries to show ambiguity in the language (something DDD looks for to create bounded contexts).
About the facilitation, you are totally right. A good facilitator is what makes or breaks it. Besides EventStorming is not a silver bullet, it has its flaws and its blind spots. So then you need your facilitator to grab out their toolbox and see how to battle this
There are many tradeoffs to consider here. If technical team has to talk to clients, well, we will lose some clients, period. Many types of clients and many types of engagements (for a software house) are simply unavailable, because we will lose out in competition with companies who will be given very good support by great client-facing specialists who will woo them, and actually give high quality consulting and value on the early stage of the project.
However, if we put those good business guys in front of the team (or as part of it), they start to lead the process, and our less developers who are usually much less ready to talk to clients etc. and have tech-related biases, suddently lose the best chance to learn. Because when someone takes away the difficult part of managing the client and trying to figure out what they need, you stop thinking about it on your own and you don't develop those mental models as fast (if at all).
There is maybe a middle ground where there's a mix of comms coming from technical and non-technical folks, who knows. In my experience this typically morphs into either model though.
Half of the good brought to the world by various movements like XP, scrum etc, is that they popularized a nomenclature for ... stuff. Most of the this we knew before, but even between programmers it was hard sometimes to explain to another what you meant. Between the design patterns and other lingo now rooted in industry, we can discuss things more easily.
Already been done! (Bonus points if it's "And I did it!")
Event Storming is a type of behavior analysis, perhaps a step up from User Story Mapping, that looks much more geared to plugging into a FP paradigm than any of its predecessors.
In the past, we've focused a lot on structure in our models. This is the flip-side, looking at behavior. And yes, author, it is most assuredly a modeling exercise.
What the heck. New buzzword, new faces, an easier path to certain kinds of deployments? Sign me up! Let's give it a shot. Might be a blast.
https://pragprog.com/book/swdddf/domain-modeling-made-functi...