It’s time to dirty our hands. In the last two posts, I presented the failure of the project. I described the idea of the business model and the requirements I had at that time. Now I would like to add a plot twist. Let’s use this business knowledge and practice some modeling techniques and the DDD approach. In this and the next two posts, we will be working on Event Storming. We will take the described domain/idea, and we will use it as a base for the workshop.
Event Storming – why should I even care?
If you saw a picture of a bunch of people standing in a room and putting their colorful sticky notes on the wall, it could be an Event Storming session. It may sound like another soft skill workshop, but we couldn’t have been more wrong in this case. Event Storming is a powerful tool for business process modeling. Not only “business” as there are even stories about people using it for planning their wedding 😉
But why the sticky notes on the wall? Because it is the easiest thing we can do. At the beginning, your only job is to put the past sentence (business event) on the note and stick it on the wall. This together with the subsequent process stages make a quick workshop session that can expose the lack of knowledge about our business process. Moreover, it’s a great way to share domain knowledge between participants. That’s why it is essential to invite domain experts, a dev team, business people, and anyone else who may have an interesting perspective on the topic.
Having a facilitator who has experience in running such workshops can also be a game-changer. They usually have a toolbox full of heuristics (today, you will also learn a few of them), which can help participants think out of the box. Moreover, facilitators usually have a tech background in creating software systems, so they can notice patterns and solve complex problems quickly.
The Event Storming technique was introduced in 2013 by Alberto Brandolini, who still actively promotes it worldwide. His book is available on Leanpub. Even though it’s 70% finished, it is the best source of knowledge about the technique.
In my local community, we have Mariusz Gil, who promotes Event Storming a lot in the international arena. He will also play a vital role in this post, but we will get back to it later.
Event Storming levels off participants’ knowledge, and helps build a common understanding and finding issues in the whole business process. It also enables us to tackle the complexity of the problem and decision making. It is essential because the business process is often split between different components or even departments. Teams working on their “part” focus and make decisions only there – “locally.” Sometimes teams are not on the same page and, as a result, they can harm the whole process. Event Storming is a tool used to avoid such a situation and to give us a big picture. Thanks to that, we can find optimal and global solutions to our problems.
There is another huge advantage of Event Storming – it helps find patterns on a problem level, which is usually harder but brings simpler solutions. As programmers, we have many libs, services, good practices, or patterns that we use daily. In other words, we focus on a solution instead of a problem. That’s why we should know the domain we are working on, and that’s flat. We knew about it already in the 70s while researching cohesion, and nothing has changed since then. The better code you want to write, the better understanding of the process and business model you need to have. There is no one better to ask than business or domain experts. On the other hand, as tech experts, we can help them with improving and automation of some problematic processes.
Event Storming is actually a set of workshops, starting with a Big Picture Event Storming (BPES). On BPES, we want to see, well… a big picture of the business process – we want to catch sight of participants’ perception. BPES is split into a few phases, and the original pizza recipe (Brandolini uses this metaphor) has around 6 of them:
- Kick-off – describes the workshop’s goals, a quick introduction of participants, and an explanation of how the workshop is going to look. It’s also a time for an optional warm-up.
- Chaotic exploration – sticking orange sticky notes to the wall. On each note, there is a past sentence that describes a business event.
- Enforcing the timeline – in the previous phase, each of the participants was sticking notes in different places. In this phase, it is important to order them on a timeline so that we see when they really occur in the whole process. Thanks to this, we can spot some duplicates or different namings for the same event.
- People and systems – events are usually triggered by particular persons, departments, internal or external systems. Now it’s time to show them in our BP.
- Problems and opportunities – till this phase, as you’ve probably noticed during the workshop, some places/events were problematic or generated disputes between participants. A hotspot is a name for such a piece of the business process. We are looking at each of them and trying to decide whether it’s a problem we should address or the opposite – an opportunity.
- Pick your problem – as we probably can’t solve all issues straight away, we should vote to prioritize them.
We could split all of those phases into smaller pieces with specific techniques, but we are not going to do it in this post, as even Alberto encourages us to experiment and work with approaches that work for us. He also points out that those phases can be different when we model an existing process, new functionality, or a startup. If you want to know more about the whole technique and go more in-depth, I recommend reading Brandolini’s book.
We will have our pizza recipe there, let’s see how it will turn out. Hopefully, there won’t be any pineapple on top 😉
The next stage after Big Picture Event Storming is Process Level Event Storming (PLES). In PLES, we focus on the solution, and we model things like we would like them to be. Moreover, a few new concepts will pop-up, like commands, read models, and business rules.
The last part of the workshop is the Design Level Event Storming, where we create a final model that can be moved 1:1 to the code. It’s quite a technical part, so usually only developers participate in it. We introduce an aggregate term here. We can also notice one more advantage of the Event Storming – it’s easier to change names or models on sticky notes than in the code. If something just doesn’t sound right to you, you throw it away or replace it with a different sticky note.
Regarding the workshop itself, it’s essential to keep in mind the purpose of doing it in our project. In other words, we should define the goal before running the workshop. Sticky notes on the wall are the visualization of the process and not the goal itself. The goal is what we want to achieve by having such visualization. It may speed up the process, its automatization, or the list of issues that occur in the process.
A titbit about my failed project
I didn’t mention that before, but it relates to this post very well, so I will do it now. From the very beginning, Andrzej Krzywda was supporting me in my idea. He ideally joins the roles of the programmer, entrepreneur, and marketer. I will tell you a bit more about Andrzej later on, but now I just want to say that he showed me how important it is to think about marketing and selling the product and talking with business people.
One day, we met with Andrzej in his house next to the forest, and he suggested that we could do a quick Event Storming of my idea. We didn’t have any agenda, phases, nor conventions regarding the colors of sticky notes. We just grabbed them, and we started to produce some events. After a few minutes, we had the following result:
I focused only on the system’s events, like “advertisement was created” or “offer was made.” On the other hand, Andrzej was thinking about events that occurred in the developer’s life and pushed him/her to look for a new job. As a result, events like “Toxic PM detected,” “Ruby/Elixir experiment started,” or “Interested in remote” popped up.
Some other ideas appeared as well. For example, we could analyze some events, like the one about adding a new advertisement and notice different types of people on the HR side. Let’s assume that a CTO is looking for some tech leads. He is notified each time an advertisement is added when the developer has finished some architectural courses/certificates. Another idea was to have a widget that could be included in external blogs and display advertisements of developers who have skills matching some post keywords. The reason for that was that people looking for developers to their teams also read blog posts :). Both of those functionalities could be paid.
This session was the biggest Aha moment for me. As a tech person, I was focused only on the system events, which is fine when it comes to Event Storming as we want to model the system, but Andrzej showed me a totally different perspective. He was thinking of how I can sell my product and get some traffic.
I decided to mention this whole story here, as I think it’s a great introduction to the next chapter. Long story short – you don’t have to stick to any strict form of the workshop. It’s also a visualization tool that you can use for different purposes.
Our form of the workshop
Alberto Brandolini says that an Event Storming workshop should not have a fixed form, and he encourages people to experiment with it. Giving it a structure and following some defined steps is a common mistake. For example, if you have something in your domain that is important and deserves its own notation – go for it! There are some default meanings of colors, like orange for events, or blue for commands, but if for some reason, they don’t work for you, don’t let them stop you, and use different colors. To give you an example, Mariusz once ran the workshop where they wanted to visualize the processes of DB operations in the application. To do that, they decided to assign specific statements (INSERT/UPDATE/DELETE/SELECT) to particular colors.
It is worth mentioning that experienced facilitators play an important role because they usually have a rich toolbox of techniques and heuristics. They can use a different set of those tools based on a group of attendees or the project type.
Although we don’t have to run all phases of BPES, two of them almost always occur: chaotic exploration and enforcing the timeline. We decided to go just with them to run BPES of the domain of this posts’ series. I wrote “we” because I invited three other people to support me with it. Each of them has huge experience in programming and gathering business requirements from customers. Ladies and gentlemen, may I present to you:
- Mariusz Gil – I told you he is going to play an important role here ;). Mariusz has been in the IT industry for over 20 years. He is passionate about designing and implementing systems with complex business requirements, machine-learning, and solutions that give real business value to his customers. Mariusz takes to conferences like a duck to water and is extremely outgoing. If you meet him at a conference, don’t be surprised that you will be talking about totally different things than IT after a few mins, and you will feel like you’ve known him forever 🙂
- Łukasz Szydło – he is one out of three mentors in a best-selling ($3M) online course for software architects in Poland. Programmer, architect, trainer, and consultant. He shares his knowledge at conferences. I’ve known Łukasz since my start in IT – he was my first mentor, and I’m delighted that I can still work with him sometimes in various projects.
- Andrzej Krzywda – founder of the Arkency software house, which is well-known in the Ruby community all over the world, organizer of wroclove.rb conference, speaker, writer, blogger. As ardent OOP enthusiasts, we like to whine about its current state, even though our points of view may differ a bit. Usually, we do it while hiking together. Lately, we did a live code review session of the Rails app, and you can watch it here.
As we know each other, our Event Storming sessions were quite casual. Thanks to them, we also had a chance to talk and share some thoughts and experiences, which was cool in those COVID times. Sometimes we were drifting and touching different topics, but as a result, we shared a lot of knowledge, and now you, my dear reader, will gain from it.
Before the workshop, I had some business requirements, and you probably know them if you read previous posts. Nevertheless, because I want to give you as much technical and practical knowledge as possible, I was open to different approaches/solutions. Considering our experience, I was pretty sure that the original idea could change a lot. That’s actually one of the most significant advantages of Event Storming – depending on how open we are, it can lead us to changes/improvements/optimization, even on the level of the whole organization.
Due to COVID, all workshops had to move online. Before COVID, there were discussions about whether it makes sense to run such a workshop remotely. Now it is a new norm. It turned out that thanks to great tools, it works pretty well. In our sessions, we used Miro, which became the standard tool for the purposes of Event Storming.
If you want to listen more about the remote aspect of ES, you can listen to one of Mariusz’s podcast episode. He is talking there with Alberto Brandolini, and I encourage you to listen to it (the episode starts in Polish, but around 04:55 it switches to English).
OK, let me show you in great detail our ES sessions now.
Ready, steady, go!
Before our first session, I sent the domain description to the guys, and I uploaded some original wireframes to our Miro board. We had them for reference, so I could quickly explain the flows on the example.
Then we started chaotic exploration. Each of us was putting events on the board. First questions, ideas, and discussions popped up. We decided to mark “nice to have ideas” as green notes. It’s a good practice as it usually unleashes creativity. After a while, our board looked as follows:
Please take a look at it and try to refer to the domain description from the first post. You can spot here that some events are organized into some kind of batches/groups. That’s the result of using a “Bulk Mode” feature in Miro. It is a useful functionality in the early phase of a workshop because it allows participants to add a few events at once. You add them as rows in a separate modal form, and after a submit, they are added as “sticky notes” to the board.
All events were added in quite random order at this stage, so we started the next phase – enforce the timeline. My task was to narrate the whole story. At the same time, I could add some additional information about some pieces, so we had a few extra discussions. Then, Mariusz presented a heuristic that he calls “fantastic four” or “0, 50, 100, 150”. We can usually use it when we observe a “binary” event – something either happened (100%) or something didn’t happen (0%). Sometimes we have two additional cases: something happened partially (50%) or there was too much of it (150%). In our case, such an event was “Advertisment’s requirements were accepted.” I had a yes/no mindset here: the recruiter accepts or disapproves the requirements. Mariusz suggested that we could try to use the “fantastic four” heuristic because in the real world, in such a situation, there is a place for negotiation. For example: “we don’t allow remote work, but you can bring your pets into work.” We wrote down this idea to consider it in a later part of the workshop.
Another typical example when this heuristic can be used is a payment process. Intuition tells us that we have only two options here: payment succeeded or payment failed. In fact, in the real world, we can have at least four cases:
- 0% – payment failed
- 50% – only a part of the payment was paid – due to some typo
- 100% – payment succeeded as it should
- 150% – user paid more than needed (typo?) – now we need to trigger a process of some refund
OK, let’s get back to the rest of our events now. We have them in the correct order now. We didn’t remove any duplicates nor needless events yet. Nevertheless, we marked some smaller, quite independent parts of the whole process, telling us about the possible subdomains. It will help us focus on smaller pieces in the Process Level .
At this stage, the board looked as follows:
Below you can also see our 90-minute session in a 90-second video:
90-minute remote #EventStorming session in 90 seconds 🙂
— Tomek Stolarczyk (@StolarczykT) April 23, 2020
With: @mariuszgil, @andrzejkrzywda, @lszydlo pic.twitter.com/j8atnRvBXy
In the next step, we put a line to separate from the results of our work. We started to put only domain events under this line – events that cause some real changes in our system’s state. At the same time, we removed some duplicates. We also agreed to skip events from functionalities that will not be implemented in the first iterations. As a result, we were able to visualize our first business process and business model.
To remove all “unnecessary” events, we used another helpful heuristic that concentrates on the event types. Mariusz told us that in his workshops, he distinguishes between 4 types of events:
- environmental events – exist outside the system – in the real-world, for example, a person entering the shop. Usually, they are not crucial for the workshop, but they help to get the context.
- UI events – we are clicking/using the UI, but we don’t “submit” our choices. We don’t change the state of the system. As an example: we can choose between pricing plans on UI as many times as we want, but until we confirm our decision, nothing actually happens in our system.
- infrastructural events – refer to technical things and don’t impact the system at all: “Event to Kafka sent”, “Metric increased”.
- domain events – the heart of the Event Storming. We should focus only on those in our workshops.
Using the above assumptions and heuristic, we changed the Big Picture as follows:
Let’s go now piece by piece, from left to right, and see what changed.
At first, we removed all events connected with lead generation:
You won’t find them in the After section because they don’t belong to our system (at least the one where we have advertisements). They happen “before”, so they can occur in the funnel. They will be essential for the marketing/sales department. We can think of another small app that measures the level of developers’ burnout. When the app recognizes that you should change your job, it can lead you to DevMountJob. 😉
Now I’d like to draw your attention to an interesting reduction of events:
Here you see in action the second heuristic I mentioned – the one about different types of events. We removed all UI events. Notice that “Added a certificate” or “Marked remote job as required” don’t change the system state at all. Those are only actions on UI. In other words, we are working on a draft of the advertisement – we are preparing it. We can describe all those events as one: “Draft was modified”. Actually, we could have no events here if we decided to have no draft concept in our system. Nevertheless, we want to have it because we want users to continue the preparation process even if they leave it for a while. Otherwise, we could remove all draft-related events, handle everything by the UI, and have only a single event when the form is submitted, and the advertisement gets to the system.
When the advertisement is ready, we get to the payment and publication process:
We have some changes here as well. When reading the domain description and my requirements, you could have the impression that I didn’t have a clear idea as for that part. That’s why we had a long discussion. Lukasz pointed out that if the advertisement is available for some period, maybe instead of going on with some pricing plans, we should sell time. If a user wants the advertisement to stay longer in the search results, then they pay a few extra dollars. We liked it, and that’s how the first business model was born. Thanks to that, we could skip all that part with pricing plans. By the way, we also put the hotspot (pink sticky note) here just to mark the place where we had some concerns.
Initially, I also had an idea that after the publication, the advertisement is read-only. I simply wanted to prevent the situation when the recruiter accepts the developer’s requirements, but then they are changed, and we have some inconsistency. In practice, the read-only mode could be really annoying. Imagine that you made a typo and want to fix it after a day or two. The first idea to solve this issue was to give a user X mins after publication to edit the advertisement. That’s why you can see a “Time for adv. edit expired” event in the first version. But then we realized that the recruiter accepts the developer’s requirements that he/she has at a given moment in time. It led us to the idea of something like “snapshot” – an offer made to the specific requirements.
Now let’s move to the offering:
Do you remember the idea of negotiations? Well, the business didn’t get it 😉 and decided that the recruiter needs to accept all developer’s requirements. We left a note about that and we could move to the last two processes: banning recruiters and developers’ skills verification. It’s important to mention that you can see them as the last ones on the time axis if you look at the whole picture. Nevertheless, each of them can occur at any time in the entire process. Sometimes it’s good to mark such a process with an indicator, but we didn’t do it.
We are going to take a closer look at banning now:
Notice that only the wording of two events has changed:
“Ban request sent” was changed to “Ban requested”
“Unban request sent ” was changed to “Unban requested”
Word “sent” slightly suggests a form of the activity. In the first version, we meant here some kind of HTTP request sent from the HTML form. In practice, in such situations, we should be opened to other options. For example, a ban request could also be made via mail, phone call, Slack, or fax, you name it. It is a small detail but often helps to notice approaches we’ve never thought about.
Now it’s time for the last process – candidate’s verification:
I decided to include this process in the first version of the product, as it shows how to integrate with the external system. Moreover, it is a long-running process. As advertisements are anonymous, I wanted to give developers some optional possibility to show their skills. In other words, they could get badges after solving some tests in the external systems like DevSkiller. You can notice a reduction of events specifying readiness and the start of the test. That’s because those events are outside of our domain, and they belong to the external system. We would only want to start the verification on our part and get the test result when it’s solved.
That would be it when it comes to our Big Picture Event Storming. In the next post, we will do a Process Level Event Storming and model each of the processes in detail – solution space. Now a quick summary and the homework 🙂
Summary
Even though the Event Storming workshop has a simple form, it’s not easy itself. It requires business thinking, which may be totally different from what we have in code or UI. It helps us to notice real business events that occur in our domain and change the state.
It’s a good idea to participate in the Event Storming workshops led by an experienced facilitator (like my guests). I encourage you to do so!
Now it’s your turn!
I hope we’ve piqued your interest with this technique and that you want to experiment on your own now, so it’s time for a call to action 🙂
Conduct a Big Picture Event Storming workshop. You can even do it alone, but the more people you convince, the better. For modeling, use the business process that you support daily. If you don’t want to use this one, you can use mine – there is enough information to do it in this and the previous posts. No excuses! 🙂
Enjoyed reading this? If you would like to see Domain-Driven Design and Event Stormings on a real-life example, don’t miss the next posts. Subscribe to the newsletter, so you will be the first to get to know about them.