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 my personal blog site.
A lot of knowledge is lost when designing and building software — lost because of hand-overs in a telephone game, confusing communication by not having a shared language, discussing complexity without visualisation and by not leveraging the full potential and wisdom of the diversity of the people. That lost knowledge while creating software impacts the sustainability, quality and value of the software product. Kenny Baas-Schwegler is a strategic software delivery consultant and software architect with a focus on socio-technical systems. He blends IT approaches like Domain-Driven Design and Continuous Delivery and facilitates change with Deep Democracy by using visual and collaborative modelling practices like Eventstorming, Wardley mapping, context mapping and many more. Kenny empowers and collaboratively enables organisations, teams and groups of people in designing, architecting and building sustainable quality software products. One of Kenny's core principles is sharing knowledge. He does that by writing a blog on his website baasie.com and helping curate the Leanpub book visual collaboration tool. Besides writing, he also shares experience in the Domain-Driven Design community as an organiser of Virtual Domain-Driven Design (virtualddd.com) and Domain Driven Design Nederland. He enjoys being a public speaker by giving talks and hands-on workshops at conferences and meetups.