A Big Picture EventStorming is a type of EventStorming where you get business and IT from an organisation into one room to explore the entire line of that business. This way we can find competing goals, ambiguity in the language, communication boundaries between contexts, and most important we share knowledge! We end up with a visual overview of our business architecture and can map our IT systems on or do for instance a value stream mapping. But we can also map and visualise coupling between contexts in Big Picture EventStorming. In this blog post, I will share my insights on how I visualise contexts boundaries in a Big Picture EventStorming.
At the start of a big picture EventStorming, we ask the participants to write down their domain events on preferable orange stickies without discussion with others. We let them put the stickies up on a paper on the wall in order of time from left to right. It will be utter chaos, you will be ‘critted by a wall of orange stickies’ (hopefully), and the participants now may think; how can we make sense of this mess! With the help of post-it adhesive labellers, we can efficiently structure the chaos by using swim lanes. Now multiple contexts start to emerge by creating communication boundaries. We can structure this by enforcing the timeline, but we are not able to hold this for long because contexts communicate with other contexts in a different point in that timeline, and we might lose sight of the overview again.
To gain a better overview, I use the long purple sticky to label policies, which we also use in other EventStorming types. A policy in a Big Picture EventStorming is an agreement of the business and usually goes something like if we do A, then we need to do B. In this case, we can use the purple stickies and place them after a domain event and write down the context that it goes to. This way we can point several outcomes of different contexts for instance to another context, giving us a more precise visualisation of coupling between contexts in Big Picture EventStorming.
Also, this post is published on the Xebia blog site.