29
.
04
.
2024
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

LLM Embeddings in Ruby - Paweł Strzałkowski

LLM Embeddings in Ruby

17
.
03
.
2024
Paweł Strzałkowski
Ruby
LLM
Embeddings
ChatGPT
Ollama
Handling Errors in Concurrent Ruby, Michał Łęcicki

Handling Errors in Concurrent Ruby

14
.
11
.
2023
Michał Łęcicki
Ruby
Ruby on Rails
Tutorial
Recap of Friendly.rb 2024 conference

Insights and Inspiration from Friendly.rb: A Ruby Conference Recap

02
.
10
.
2024
Kaja Witek
Conferences
Ruby on Rails

Covering indexes - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Ruby on Rails
Postgresql
Backend
Ula Sołogub - SQL Injection in Ruby on Rails

The Deadly Sins in RoR security - SQL Injection

14
.
11
.
2023
Urszula Sołogub
Backend
Ruby on Rails
Software
Michal - Highlights from Ruby Unconf 2024

Highlights from Ruby Unconf 2024

14
.
11
.
2023
Michał Łęcicki
Conferences
Visuality
Cezary Kłos - Optimizing Cloud Infrastructure by $40 000 Annually

Optimizing Cloud Infrastructure by $40 000 Annually

14
.
11
.
2023
Cezary Kłos
Backend
Ruby on Rails

Smooth Concurrent Updates with Hotwire Stimulus

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

Freelancers vs Software house

02
.
10
.
2024
Michał Krochecki
Visuality
Business

Table partitioning in Rails, part 2 - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Backend
Postgresql
Ruby on Rails

N+1 in Ruby on Rails

14
.
11
.
2023
Katarzyna Melon-Markowska
Ruby on Rails
Ruby
Backend

Turbo Streams and current user

29
.
11
.
2023
Mateusz Bilski
Hotwire
Ruby on Rails
Backend
Frontend

Showing progress of background jobs with Turbo

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

Table partitioning in Rails, part 1 - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Backend
Ruby on Rails

Table partitioning types - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Backend

Indexing partitioned table - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Backend
Postgresql
SQL Views in Ruby on Rails

SQL views in Ruby on Rails

14
.
11
.
2023
Jan Grela
Backend
Ruby
Ruby on Rails
Postgresql
Design your bathroom in React

Design your bathroom in React

14
.
11
.
2023
Bartosz Bazański
Frontend
React
Lazy Attributes in Ruby - Krzysztof Wawer

Lazy attributes in Ruby

14
.
11
.
2023
Krzysztof Wawer
Ruby
Software

Exporting CSV files using COPY - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Ruby
Ruby on Rails
Michał Łęcicki - From Celluloid to Concurrent Ruby

From Celluloid to Concurrent Ruby: Practical Examples Of Multithreading Calls

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

Super Slide Me - Game Written in React

14
.
11
.
2023
Antoni Smoliński
Frontend
React
Jarek Kowalewski - ILIKE vs LIKE/LOWER - Postgres Stories

ILIKE vs LIKE/LOWER - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Ruby
Ruby on Rails
Postgresql