After the Big Picture: Turning Insights into Action

Now that you understand what Big Picture Event Storming is, how to facilitate it, and how to overcome common challenges as a facilitator, I believe the series of articles we’ve explored — walking through its steps and possibilities — demonstrate that the knowledge gained by everyone involved truly justifies the time invested in the workshop.

That said, the objective is to cover various stages of developing a Training Center application, to illustrate how techniques like Event Storming, microservices, event-driven architecture, sagas, and many others can work synergistically to improve product quality, architecture, and code. So the natural next question is: what comes after the Big Picture?

We defined a timeline, but… what’s next?

We now have our comprehensive, well-structured timeline:

Of course, one option is to leave it at that and move forward. We have already learned a great deal, established a shared understanding, and raised awareness about potential problems and issues. Even with this approach, the time spent is far from wasted.

On the other hand, we can leverage the Big Picture outcomes as inputs that assist us with several critical tasks:

• Assessing the risk level of starting development at this stage

• Defining domain boundaries

• Identifying which processes should be explored next

Before diving deeper into these points, I want to emphasize two things:

• The Big Picture outcome is something to aid your thinking, not a definitive answer. It supports a more data-driven approach, but other factors may carry greater weight.

• Big Picture Event Storming was never intended to be precise or exhaustive. It’s not a perfect representation of the domain landscape — you must remember that things will evolve and become clearer as you learn more.

With that in mind, let’s take a closer look at how to further utilize the artifacts produced during the Big Picture workshop.

How to assess project risk?

Thanks to the hot spots — their quantity and nature — everyone becomes aware of unknowns, difficult questions, and unvalidated solutions. First, this dispels naive questions like “why is this taking so long?” and gives the team solid arguments to discuss risks seriously.

How do hot spots help? The more hot spots you have on the wall, the riskier the project is — simply because of the number of open questions that need answers. You can gain deeper insight by reviewing each hot spot and evaluating its impact on risk. For example, “What exactly defines Personal Data?” might influence analysis time but not risk directly, whereas “Is this even possible?” signals a much bigger concern.

Next, examine the events surrounding these hot spots. If we are building a Training Center and have a hot spot like “Is this even possible?” next to the event “Training Program Added” (which is likely crucial to the business), an incorrect answer could jeopardize the entire project. Conversely, the same hot spot near “Discount Used” might just result in deferring discount features for now.

I highly recommend conducting this exercise with your stakeholders and sharing the results to create heightened awareness of the current situation.

Also, don’t get too fixated on these decisions. Even if dozens of hot spots suggest significant danger, someone may still decide to proceed. That’s their call, and you should respect it. The benefit is that the decision is undoubtedly more informed after the Big Picture workshop. Ultimately, sometimes the potential rewards outweigh the risks.

Defining system boundaries

Pivotal Events, Swimlanes, Actors, and External Systems—represented as sticky notes—help us define more precise boundaries for the system we plan to build. These boundaries can later serve as valuable input when modularizing code or defining deployable services.

How do these sticky notes help?

• Pivotal Events highlight where something important occurs. If a follow-up reaction happens after an event, that event may indicate a natural boundary.

• Swimlanes represent steps in the process. Everything under one swimlane can be considered to be within certain boundaries.

• Actors who trigger multiple events may suggest those events belong within the same boundary.

• External Services occurring alongside multiple events might be a cue to group those events within the same boundary.

Of course, this is just scratching the surface — there are additional technical and non-functional aspects to consider before finalizing boundaries. Yet, the Big Picture workshop’s outcome certainly helps focus those decisions on what the business requires the software to support.

Don’t worry if you want to dive deeper into this topic; we will explore it thoroughly in upcoming articles.

Deciding which process to explore next

Looking at the Big Picture can feel overwhelming. On the positive side, everyone recognizes the domain’s complexity — no one will underestimate it as “a few more buttons.” On the flip side, you still need to answer a critical question: where should you start?

Here are several approaches:

• Focus on essential processes (your “must-haves”) that have many hot spots — this indicates uncertainty and warrants dedicated exploration.

• Look at processes with the highest number of events. Numerous events can signal long, complex processes or strong stakeholder interest. However, this can sometimes be misleading if the right people were not present and the focus was on trivial matters. This is why facilitators must ensure the right participants are involved.

• Hold votes on pivotal events — allow the team to decide which events are most important. (As you know, there are several voting techniques; pick one suitable for your situation.)

• Combine all the above. Remember, the number of sticky notes (events or hot spots) should not be blindly trusted. A single event might not indicate a simple process but instead a lack of understanding or missing stakeholders. Likewise, no hot spots in an area could mean the same. Combining approaches usually yields better decisions.

Summary

As you can see, the Big Picture workshop delivers much more than just a better understanding of the domain. It produces a valuable artifact that aids management, architectural, and analytical decision-making.

This is something I personally love most — when you combine techniques that help you build high-quality software, they naturally lead you to next steps and reinforce one another. Using them together delivers benefits beyond their individual strengths.