EventStorming: Continuous discovery beyond software modelling
1–10 of 19 posts
Re: EventStorming: Continuous discovery beyond software modelling
#2So, deciphering this BuzzwordStorming: you get together and model your business domains in a group, using visual aids.
Quite revolutionary! cough
Re: EventStorming: Continuous discovery beyond software modelling
#3Re: EventStorming: Continuous discovery beyond software modelling
#4> 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 Buzzwo…
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.
Re: EventStorming: Continuous discovery beyond software modelling
#5https://pragprog.com/book/swdddf/domain-modeling-made-functi...
Re: EventStorming: Continuous discovery beyond software modelling
#6> 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 Buzzwo…
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:
Re: EventStorming: Continuous discovery beyond software modelling
#7I recommend this book n which this method is described and explained. Also F#. https://pragprog.com/book/swdddf/domain-modeling-made-functi...
Re: EventStorming: Continuous discovery beyond software modelling
#8> 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 Buzzwo…
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.
Re: EventStorming: Continuous discovery beyond software modelling
#9> 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 Buzzwo…
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 does…
"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.
Re: EventStorming: Continuous discovery beyond software modelling
#10> 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 Buzzwo…