We believe we are one of the very, very, very few companies actually applying this technique in Vietnam. At Silentium Vietnam, we rely on the technique daily; it's not because it is cool (it is actually cool); it is because the technique ticks many items in our checklists.

Once we give it a try, we right off see the value it brings across the board. The first time, we see our engineer so into a workshop (partly because they are benefiting from that without reading tons of documents)

This is the story about how do we get into Eventstorming and stormed it out

Pre-intro

I myself interview a lot of people carrying a lot of different responsibilities in Product Development. One of the questions I always ask those, "How do you know that you are doing a wrong thing?". And, the reason why I ask the question is rather selfish; I want to learn from their thinking process; By chance, I may acquire a trick or two.

Along the line, I start to ask myself, well, how do you know that you are doing something wrong?

You may have heard about the "Regression test"; that's like when you are plugging an electronic device at home, and popped! a light bulb in the toilet burned due to over-voltage, who can think of that, right? And it is not even something special; it happens all the time in the software development world. The whole Fastly CDN (serving traffic for Twitch, Reddit, and Pinterest) roughly down for an hour due to a valid configuration from the customer, to tell you how devastating a regression can be.

You may think, well boys, they should be aware of this when implementing the feature, then think about this. People come and go, the team comes and go, the system is not as documented, complexity between systems, etc. The regression about to happen can be in charge of someone in India, while the one who is making change is somewhere in a corner in Singapore.

Such a rant! Regression is one of those things; think further and asking yourself. "Well, can a <name> prevent this from happening?". Fill in whatever title you like; the answer is always going to be "it depends because it is complicated."

Tackle the hard thing

Let's have a deep look into the problem we are talking about and zoom out; we'll see

There are actually quite a few attempts on the topic; we have UML (I barely remember a few of those notations), BPMN (Business Process Model and Notation), which is super rich notations - are all tried to bring people together (as in, business people, product people, engineers, and designers) but, I guess, those attempts were way too much of engineering. The languages and representations are not natural to non-engineers; hence, Eventstorming, the next attempt.

Introduction to Eventstorming

EventStorming is a flexible workshop format for collaborative exploration of complex business domains. It comes in different flavors that can be used in different scenarios: to assess the health of an existing line of business and to discover the most effective areas for improvements; to explore the viability of a new startup business model; to envision new services that maximize positive outcomes to every party involved; to design clean and maintainable Event-Driven software to support evolving businesses rapidly. The adaptive nature of EventStorming allows sophisticated cross-discipline conversation between stakeholders with different backgrounds, delivering a new type of collaboration beyond silo and specialization boundaries.

The definition we copied from the homepage of Eventstorming