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

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

A look back at Friendly.rb 2023

14
.
11
.
2023
Cezary Kłos
Conferences
Ruby

Debugging Rails - Ruby Junior Chronicles

14
.
11
.
2023
Piotr Witek
Ruby on Rails
Backend
Tutorial

GraphQL in Ruby on Rails: How to Extend Connections

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

Tetris on Rails

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

EURUKO 2023 - here's what you've missed

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

Easy introduction to Connection Pool in ruby

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

When crazy ideas bring great time or how we organized our first Conference!

04
.
12
.
2023
Alexander Repnikov
Ruby on Rails
Conferences
Visuality

Stacey Matrix & Takeaways - why does your IT project suck?

14
.
11
.
2023
Wiktor De Witte
Project Management
Business

A simple guide to pessimistic locking in Rails

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

Poltrax design - story of POLTRAX (part 3)

04
.
12
.
2023
Mateusz Wodyk
Startups
Business
Design

Writing Chrome Extensions Is (probably) Easier Than You Think

14
.
11
.
2023
Antoni Smoliński
Tutorial
Frontend
Backend

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