The tree swing analogy is well known for its epic visualization showing the difference of how each department interprets and implement a requirement in the development of a tree swing.

When focusing on software systems, business processes were represented by technical modelling approaches helping developers write the software solution in their own language, yet leaving the domain (business) experts behind.

By reducing the gap between project stakeholders (both technical and non-technical) and bringing them together in an easy, fun and yet effective format to explore the business domains, a common understanding and acceleration of development teams will be achieved.

Domain experts are not left behind when using technical modelling approaches. They are not interested in databases, abstraction or design patterns.

Technical people are involved in the system big picture and co-share the perspective of domain experts, including business objectives, personas and system goals.

One way to achieve that, is by using a shared vocabulary (aka Ubiquitous Language) between involved stakeholders, a language not biased to either business or technical direction.

Techniques

There are many techniques to achieve that, for instance:

• EventStorming
• Domain Storytelling
• User Story Mapping

In the following lines we will explore how we made use of EventStorming to better understand our business domain and how we integrated it into our agile process.

EventStorming in a nutshell

EventStorming is a workshop-based method invented by Alberto Brandolini to quickly find out what is happening in the domain of a software program. The basic idea is to bring together software developers and domain experts to explore complex business domains and learn from each others‘ perspectives.

You can tailor and design your own workshop thanks to its open platform, from Big Picture to fine grained design of a software-oriented solution.

As the name implies, Events are playing an essential role in EventStorming. Events are facts that already happened in the system. For example; User Created, Item Added, Item Removed.

Brining all EventStorming concepts together, EventStorming process modelling could be seen as:

Given the information available in the Read Model, a User will trigger a Command on a piece of software (Aggregate or External System). This will result in an Event being issued, and listened by one of more Polices, that in turn will issue Commands.

How does it work:

Invite the right people

For EventStorming to be successful, you need the right people to take part. But wait a minute who are the right people?

According to Brandolini, they are the people who know the right questions to ask and the ones who have the answers. This group will likely be a mixture of stakeholders being UX, business, architecture and development.

Provide unlimited modelling space

It is essential to provide ‚unlimited‘ modelling space (either a wide wall, a very long piece of paper or virtual board), a lot of colored sticky notes and markers.

Explore the business domain

Now you have all what you need to start exploring the business domain.

How did we start?

Collect

As we started, our main goal was to break the ice with domain experts and make it clear we are not going to speak about technical aspects; therefore, we started with so called Big Picture where:

• Clear timeline was defined. Timeline has a start and an end.
• Everyone was invited to write events, a lot of events that fit within the defined timeline.
• At this point, uncertainty and bottlenecks start to emerge; therefore, we made them visible using an annotation called Hot Spot

Sort

After defining a lot of system relevant events, more important ones defining key moments in the flow were selected and we started to sort up the other events around them.

Adding people and systems to the model triggers both human and system reactions.

Explicit Walkthrough

At that moment, we needed to validate our common understanding by:

• Telling the story
• Validating the story
• Verifying that the model is in sync with the story

One started to tell the story from left to right, while others tried to validate it, resulting in adding more events, splitting them into swim-lanes, removing or writing other events.

Even more we started to tell the story in reverse. Doing so even more insights were collected, things we forgot or misunderstood.

Outcome

From the Big Picture, we were able to group some events together, define dependencies, set boundaries and as technical people we gained the trust of the domain experts.

Gain more insights

In the next sessions we focused on Process Modelling. Exploring only a specific part of the business process, filling the board with more information (Policies, Commands, Read Models) and hotspots were addressed.

The goal was to connect the events from the starting point to the final state.

Agile/Scrum 

According to the fourth Agile principle from Agile manifesto 

Business people and developers must work together daily throughout the project

we see that EventStorming goes hand in hand with the Agile method. 

In order to bring EventStorming blueprint from the board into reality and use it in daily business, we followed the simple principle – if it’s on the board, it should be represented in the code.

So, the next step was to transform the EventStorming model into epics and user stories. This transition went rather smoothly.

• Identify a specific business process to implement.
• Write user stories for it using command, event, policy and read model terminologies
• Proceed to refine them – most of the questions came up already during EventStorming phase.
• Include the refined user stories into planning.
• Implement them.
• Gain more insights and repeat.

Tooling

With Corona pandemic, we have moved to mobile working and had to find an alternative where we could continue our EventStorming sessions and keep above mentioned principles in mind (right people, unlimited modelling space, interactability).

The online tool which we use for our online EventStorming session is miro.com (Online whiteboard for visual collaboration).

This tool also has the option for multiple users to work simultaneously and see the results in real-time. Cursor-Tracking feature was also helpful during discussions.

Conclusion

Advantages:

• It provided a common space for Business, IT and UX people and whoever is interested in discovering the Big Picture of the process.
• It served as living documentation for our system.
• The process is now visible and explicit.
• We were able to identify process bottlenecks.
• We gained massive learning crossing silo boundaries.
• Business learns Business – By bringing all interested people together sharing the same picture and understanding.
• The only challenge is, there are not enough Orange and Lilac Post-its

Takeaway:

• Keep the problem clear and simple.
• The color grammar must be respected. Orange is an event; Blue is a command.
• Focus on domain concepts, like policies and business processes. Try make them explicit not implicit.
• Do not fall into the trap of trying to answer every question to every problem. Use hotspots instead. Here the facilitator came to the rescue.
• List all scenarios you may want to support. Pick the simplest one and model an end-to-end solution.
• Whenever you spot an alternative path, take a note of the new scenario and add it to the list.
• Do not try to solve both scenarios at the same time, solve the simplest first, then see how the existing model performs with the new scenario.
• Each time you will explore new insights. Use them to revisit your model.

EventStorming and Domain Driven Design (DDD)

I intentionally did not mention DDD until now, but actually EventStorming is such a great way to introduce DDD even without naming it.

EventStorming has its roots in the DDD approach and you can clearly see that with its concepts like Event, Aggregate, Bounded Context, Domain yet you do not need to use DDD in your team.

When combined with supporting architecture, EventStorming provides a great way to reflect what you model with domain experts and what you write in the code.

In the next blog posts, we are going to take you through different architectural patterns which perfectly work with EventStorming.