Team days are something wonderful. Here, you can unfold, gain new insights, and share with each other. Recently, we had such a team day themed "Topic Intensive", where we could focus on various topics detached from project work. As an aspiring enterprise architect, I was drawn to the topic of architectural methods.
The plan was to explore various methods of knowledge crunching (such as Event Storming and Domain Storytelling) through concrete examples like "booking project times" and "performance records". We aimed to exchange our team's previous experiences on these topics during the "Topic Intensive" team day.
On that day, our group consisted of seven architects, one domain expert from the back office, and a facilitator who had prepared by delving into the methodologies beforehand. In addition to experiencing the methods, we aimed to address specific questions:
- Which problem do I address with which methodology/technique?
- Which methods/techniques can we combine and which results are essential for what?
- What support tools are available?
After the obligatory check-in, things got off to a stormy and eventful start.
Event Storming
We began with Event Storming on the topic of "booking project times." We deliberately allocated only a one-hour time slot, knowing that this wouldn't comprehensively cover the topic.
Event Storming is a lightweight method used to make domain expert knowledge tangible and understandable. It helps to establish a common language and elevate all participants to the same level of understanding. This method requires no computer or IT tools—just a wall and sticky notes (stickies). In addition to capturing current processes, as in our case, Event Storming can also be used to develop future state (to-be)processes. It's crucial to agree on a scenario beforehand for effective collaboration.
The outcome of Event Storming typically isn't a finalized BPMN-style documentation, but rather a shared understanding of the domain. Since much of the knowledge is shared through discussions at the wall, subsequent understanding by third parties, who were not present, is limited.While there are theories suggesting not to capture the results, in practice, I believe it provides a good foundation for further steps.
For Event Storming, involving the right people with domain expertise is crucial. In our chosen topic, this includes Anke from the back office, who processes the bookings, as well as the experts who handle booking and approvals. At the outset, a brief explanation is given to all participants about the concept of Event Storming (building shared knowledge—mentally) and the types of stickies (concept elements) involved.These stickies are typically color-coded, with each color representing a different type.
You start with domain events on orange stickies. These are structured as a noun and verb in the past tense, for example, "hours submitted" or "hours verified". (These describe the "event that occurred."). The rationale behind this is that completed events do not require discussion about their duration or when they specifically started.
As you place these events on the wall, it quickly becomes apparent how broadly people think about a topic and what is actually needed to handle a simple topic like "booking project times". In our case, it began with the event "project created," as a project is necessary to book times on—something I wouldn't have thought of myself. Due to our time box being only one hour and discussions involving both domain knowledge and the method itself, we didn't progress much beyond the domain events.
While placing the stickies on the wall, the person placing them typically explains what they mean, which can spark discussions to ensure understanding. Usually, temporal dependencies are also modeled directly on the wall by arranging the stickies in sequence. By the end of the hour, we quickly added Actors (yellow stickies representing individuals performing actions) and Views (light green stickies representing how the Actor interacts with the system) to some events to make the next steps in the methodology clearer.
At the end, what's particularly interesting is whether all domain events have been identified and considered. To determine this, one can review the chronological sequence from start to finish and then from finish to start to check if all prerequisites for an event are fulfilled.
Since we also aimed to learn about the methodology, we conducted a debriefing afterward to evaluate our experience.
Our Findings
- One hour is very short, even for small topics. We did not get beyond the domain events and there are certainly still gaps even there.Based on the experience of architects who already use the methodology, we believe that 4 to 8 hours per topic should be planned.
- It is very interesting how big even a small topic can become when you have different participants. Swarm intelligence is a big success factor here to get a comprehensive view.
- It actually seems to be easier for techies to think in terms of events than for non-techies. I had only read this before but now I can understand it.
- The roles (moderator, domain expert, architect) should be clearly defined, especially when used in parallel as a real workshop and knowledge transfer. When using this technique, there should be no discussion about the methodology (color of the notes, what is an aggregate and what is not). Good moderation is very important here.
- Separate moderation and content-related collaboration. → If event storming is to work as a method, then only use the moderator for moderation. If you want to work out and influence technical aspects, then you should go into the meeting in pairs.
- If, in addition to the event storming, subsequent architectural work is to take place with the results, then the architect must be present at the meeting. As a rule, no meaningful statements can be derived from the output alone, as the detailed knowledge is often more on the audio track. Architectural work can be, for example Documentation (note: the result of event storming is not yet documentation), deriving risks, recognizing hotspots and redundancies.
- I have subsequently read that up to 15-20 people can take part in an event storming. After the first experience, this is probably too many - try 5-10 if you are using this methodology for the first time.
- You don't need any IT tools. A large wall and stickies are sufficient
- In subsequent Event Stormings, the variant where everyone sticks only three events at the beginning and then it's the next person's turn has proven to be very effective. This method allows all participants to get involved and start talking.
Event Storming, in my view, is well-suited as an entry-level approach at a very high abstraction level—BigPicture. However, its results can also be used to delve deeper. We did this by splitting into two groups afterward. One group used Domain Storytelling to delve deeper into the "performance records" area, which we had identified as a hotspot. The other group aimed to refine the result and use another step of the methodology to divide into domains or bounded contexts.
Since I was in theDomain Storytelling group, it's about to get a bit fairy-tale-like—or maybe not quite so much 😀.
Domain Storytelling
To delve deeper into the hotspot topic of"performance records" and gain a better understanding, we utilized the Domain Storytelling method. In this approach, a domain expert narrates their activities as a story, which is then visualized. Alongside the expert, we had a dedicated moderator, a visualizer, and three additional architects who contributed knowledge and could ask questions for clarity. Once again, we limited our time to one hour for this session.
Methodology
Domain Storytelling involves conducting an interview with a subject matter expert. During this process, the expert tells a story using simple sentences following the pattern <Subject – Predicate –Object>. The subject is always an Actor (person or system) performing an action (predicate) on an object. The action may involve another Actor, connected by a preposition. Each sentence is discussed until everyone agrees it is accurate. Once accepted, the story progresses to the next point.
This approach differs from Event Storming, where elements can be rearranged and questioned freely throughout the process. At the end of Domain Storytelling, the sentences form a coherent narrative. The method can be conducted using analog stickies or supported by digital tools.
Tool
For Domain Storytelling, we used the tool Egon.io, as some colleagues already had experience with it and it is recommended on the methodology's website for support.
In Egon.io, sentences are visualized by selecting from a set of Actors and Objects, which are connected by arrows. The arrow automatically receives a number (indicating the sequence in the story) and a description of the activity. When involving another Actor, a second arrow is drawn between the Object and the Actor, with a preposition written on it. No number is assigned to this arrow.
It's notable that you can add custom symbols forActors and Objects in Egon.io to personalize the story. With a clear understanding of the context, preparation can be done effectively.
At the end, two very different versions of the same story emerged. After all, our goal was to learn and experiment.
The spider diagram in Egon.io represents the entire story graphically. Starting from the center—the narrating person—sentences branch out in all directions. This visualization allows us to see how many applications are in use, which applications are used frequently, and where there are media breaks. It also highlights that for what seems like a simple step, several sentences (extracted, exported and imported) and tools are necessary.
However, the process can also be broken down into smaller chunks. A colleague introduced this approach, having used it before. It deviates from the idea of having each Actor appear only once in a story to create a connected graph. Instead, this method limits each Actor to 2-3 tasks, allowing the Actor to appear multiple times and telling the story sequentially from top to bottom. This approach simplifies the image and is more suitable for creating a readable, personalized documentation.
Regardless of which methodology you choose, egon.io offers the ability to replay the story step by step in replay mode at the end.This feature allows, for example, the moderator to review and ensure that everything is included in the story.
Our Findings
It's beneficial to apply the technique with two people when using Egon.io. One person leads the workshop and keeps the story flowing, while the other person visualizes it. Through visualization, the narrator can provide immediate feedback on accuracy and understanding.
Sometimes, it can be challenging to engage domain experts in storytelling. It's crucial to keep the requirement straightforward—there's no need for a Harry Potter or the best bedtime story for children. Therefore, exaggerating the fantastical elements should be avoided to prevent misconceptions among domain experts. We certainly had a learning experience in this regard.
Using egon.io is intuitive and user-friendly. However, it's advisable not to use the tool for the first time during a session.Introducing custom symbols enhances comprehension, particularly when tailoring the story with symbols relevant to the domain or customer. The feature to replay the story based on sentence numbers at the end is excellent for clarifying understanding.
And Now?
Here again, participants gain a shared understanding of the domain and its tasks through Domain Storytelling. This understanding can be preserved for later documentation or used for analyzing pain points.Alternatively, the results can be used to onboard new team members, ideally shortly after the session. During onboarding, someone who participated can retell the story using the visual representation. It's essential that this remains a conversation, with someone narrating who was present during the original session.
Cutting Domains / Bounded Contexts
The second group focused on the topic of "FindingBounded Contexts." Specifically, they addressed the questions: What is it?Why do we need bounded contexts? And how do we find them? Since I only attended the final presentation, I'd like to show you the exciting results and provide abrief summary.
Typically, segmenting into bounded contexts is a step to identify logically related events that can later function as independent modules with minimal coupling within the overall system. This approach allows for independence in software implementation. This "loose coupling"can be extended to teams, reducing the need for extensive coordination with other teams during development, and any necessary coordination can occur through predefined interfaces.
For the process of segmenting, domain experts generally know precisely where boundaries can or should be established.Therefore, these questions should be posed directly during the Event Storming workshop. Boundaries can be identified, for example, where there is a change in roles (Actor), at temporal boundaries, or when there are shifts in language within the model, such as differing interpretations of "booking" at different points.
Events that cross boundaries between contexts or are used by multiple contexts are called Pivotal Events. These events typically lend themselves well to achieving asynchronous coupling between contexts in a target architecture.
Overall Conclusion
Team days are great because they allow you to take thetime to explore new topics and practice new methods in a focused and protectedenvironment.
For me, Event Storming is primarily a methodology todraw the Big Picture of a domain. Delving deeper can then be done with othermethodologies. Obtaining a comprehensive picture depends greatly on havingdomain experts involved. It's important to include all relevant experts.
I found going deeper with Domain Storytelling to bestraightforward and effective, provided that the domain expert is well engaged.If a diagram like the spider diagram we created emerges, then egon.io's replaymechanism is helpful for step-by-step review.
Both methods are not documentation tools but rathertools for knowledge sharing. The barrier to entry is very low, as both are easyto understand and not very complex.
So, give them a try!
