14
.
11
.
2023
3
.
08
.
2022
Event Storming
Visuality

We started using Event Storming. Here’s why!

Mariusz Kozieł
Chief Executive Officer

“Software development is a learning process, working code is a side effect.” - Alberto Brandolini

The first time I bumped into Event Storming was around 2 years ago. I was participating in the course ‘The way of the modern architect’. It's a Polish course for advanced programmers/architects. That time I wasn’t impressed, I was more into the C4 model and other techniques. This year a few people from the Visuality team and I were part of another course ‘Legacy fighter’. This time teachers convinced us and we decided to try it.

It's not an article where I will be explaining the concept of Event Storming. I suggest watching Alberto Brandolini's presentation. Personally, I have learned from multiple articles, presentations, and awesome event storming repository created by Mariusz Gil. Mariusz is one of the best ES specialists in the Polish community. He gathered a lot of sources and examples.

In the beginning, ES was quite difficult. The further the more complex it was. There are so many details and different approaches to various needs. I was afraid of how to do it but there was a need because we had planned to conduct a session for one of our clients.

In the end, I have decided to do the first session where we can learn on real project. Even Mariusz Gil suggests to make Big Picture Event Storming on your own, a well-known process. So learn on real examples even alone. When you start putting stickers on the wall the journey begins 🙂

We have decided to make ES on our start-up Poltrax. The project was a blank page for some of us. It was conducted by Paweł, the most experienced engineer with ES technique in Visuality. We have gathered the most important people in Poltrax. It was great to see how we explored the application in 2 sessions which took 5 hours overall. Even people who invented Poltrax discovered something new about their product.

We were able to do Big Picture but we have also found some future improvements on the road. We have planned flexible architecture which supports those requirements.

Big Picture Event Storming

The first Event Storming session impressed us so we were glad to do another. The second ES workshop was made with a different team. It was the ES that was done as a project retrospective. We took the application as is and planned how we could do it better. It took longer than the previous one but we dove deeper; Big Picture level but also the Process Level of ES.

We have planned new architecture. Requirements were complex, it was difficult to forget current implementation so we had problems establishing proper architecture. Even though we had problems and we were on a learning curve we achieved awesome results. Now we know that we should go deeper with ES Design Level, but we still want to come back to it.

Big Picture and Process Level Event Storming

After a few training sessions, the time has come for production workshops. We traveled to Krakow to our client's office. Whole team, around 10 people in one room. We had an opportunity to make only the Big Picture. We have gathered knowledge about a new project but also the client's team used it. Even participants who were in the project for a long time already found a lot of unknowns and they were on the same level of business processes at the end.

After the ES, the next day, we could jump to the ideas to improve the codebase and how we can divide the application into microservices to fight with performance and accessibility. I can’t imagine that we could talk on that level of understanding after one day of workshops.

Big Picture Event Storming with a client

After that session, one of our engineers declared that he knows as much as he knows about his project which he has worked on for the year. It's impressive. It proved that ES really reduces the distance between IT and business. Being on the same level of understanding leads us to be partners who can help grow the business. Engineers can suggest the best solutions. They shouldn't be machines who implement tasks without business knowledge.

I am fascinated by how ES progresses. From chaos where numerous stickers are put on the wall without any order into the full process with alternative paths. It's impressive how many discussions are on the road to well-understand business at the end.

We still have to learn more about ES and we are doing that. Paweł took part in the Mariusz Gil advanced course which was awesome. We are planning next sessions and we would like to jump into the Design Level of Event Storming.

I suggest not to be afraid and start learning from the Big Picture level, which is awesome on its own. Do it alone on a well-understood process. Then the technique pulls you in itself.

To sum up, Event Storming practice is introduced as Visuality standards. It will be preferably approached to do workshops with new clients or with new big features.

Mariusz Kozieł
Chief Executive Officer

Check my Twitter

Check my Linkedin

Did you like it? 

Sign up To VIsuality newsletter

READ ALSO

Bounded Context - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

The origin of Poltrax development - story of POLTRAX (part 2)

29
.
11
.
2023
Stanisław Zawadzki
Ruby on Rails
Startups
Business
Backend

Ruby Meetups in 2022 - Summary

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Visuality
Conferences

Repository - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

Example Application - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

How to launch a successful startup - story of POLTRAX (part 1)

14
.
11
.
2023
Michał Piórkowski
Ruby on Rails
Startups
Business

How to use different git emails for different projects

14
.
11
.
2023
Michał Łęcicki
Backend
Tutorial

Aggregate - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

Visuality at wroc_love.rb 2022: It's back and it's good!

14
.
11
.
2023
Patryk Ptasiński
Ruby on Rails
Conferences
Ruby

Our journey to Event Storming

14
.
11
.
2023
Michał Łęcicki
Visuality
Event Storming

Should I use Active Record Callbacks?

14
.
11
.
2023
Mateusz Woźniczka
Ruby on Rails
Backend
Tutorial

How to rescue a transaction to roll back changes?

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Backend
Ruby
Tutorial

Safe navigation operator '&.' vs '.try' in Rails

14
.
11
.
2023
Mateusz Woźniczka
Ruby on Rails
Backend
Ruby
Tutorial

What does the ||= operator actually mean in Ruby?

14
.
11
.
2023
Mateusz Woźniczka
Ruby on Rails
Backend
Ruby
Tutorial

How to design an entity - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

Entity - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

Should I use instance variables in Rails views?

14
.
11
.
2023
Mateusz Woźniczka
Ruby on Rails
Frontend
Backend
Tutorial

Data Quality in Ruby on Rails

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Backend
Software

We started using Event Storming. Here’s why!

14
.
11
.
2023
Mariusz Kozieł
Event Storming
Visuality

First Miłośnicy Ruby Warsaw Meetup

14
.
11
.
2023
Michał Łęcicki
Conferences
Visuality

Should I use Action Filters?

14
.
11
.
2023
Mateusz Woźniczka
Ruby on Rails
Backend
Tutorial

Value Object - DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial

Introduction to DDD in Ruby on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Domain-Driven Design
Backend
Tutorial