Identify relationships between services in a complex system to reveal the notional target system architecture and record them using SNAP
1.5 hours per run; multiple runs are often needed
Business stakeholders, architects, technical leads, developers
The Boris exercise comes after Event Storming since it uses insight discovered by that activity to identify system components and model their relationships
After Event Storming, using one color of sticky notes create one for each bounded context. Place on the board in a blob.
Discuss a thin slice of the flow and map out how each of the bounded contexts communicate with one another to complete the flow. Start with the happy path then move to unhappy paths.
If the event message payload is discussed, push to use the smallest message possible with the least number of unique keys to identify a unique bounded context through a synchronous web service lookup (“lean events, rich APIs”)
Draw a line from system to system as they talk, using different colors for synchronous and asynchronous communication. Add arrows to indicate if it is pushing or pulling.
Questions to think about:
Indicate if a queue is needed by adding them in a new sticky note of the same color for a queue/topic. Add in the lines for what systems are talking to it.
Using a new sticky note of a different color, indicate if there are external systems as part of the flow. Add in the lines for how it is communicated with in the flow.
Create SNAP lists on large sheets.
SNAP takes the understanding from the Boris diagram to understand the specific needs of every bounded context under the new proposed architecture. The SNAP exercise should be done for each bounded context and call out APIs, data needed, UIs, and risks that would apply to that bounded context. The backlog for the product will be created based upon the items identified.
Questions to think about:
As you discuss the flow and the interactions with the system you can add information to each bounded context’s sheet
Move on to the next flow indicating this in a new color
Add info on the new flow to the larger bounded context sheet on a new sticky note color
Call out specific areas that are missing on the bounded context sheets that are missing.
At the end of a Boris exercise, Services, APIs, Data and Event Choreography and a backlog of work starts becoming obvious.
SNAP is used to quickly document the outcomes of a Boris in real-time. Information is often grouped into APIs, Data, Pub/Sub, External Systems/UI, Stories, and Risks. The key artifact is a poster-sized sticky paper on a conference room wall or similar from a digital workspace, with one SNAP per node or service depicted on Boris. Typically there will be one SNAP per node or service depicted on Boris. Each SNAP consists of documentation about six categories: APIs, Data, External Systems/UI, Pub/Sub, Stories and Risks.
Boris, Event Storming and other techniques are part of the Swift Method that we use for identifying the “real” problems in a large scale system and discover the North Star direction for your modernized system. Let the solution present itself through rhetorical questions. Practice a fine balance between driving to a solution vs organic evolution of the target architecture. Do not pre-optimize during the Boris exercise.
Challenge: It isn’t clear when to move from Event Storming to Boris to SNAP.
Once the room has slowed down putting business events up and have had at least one round of explicitly putting up pain points, you can try identifying the aggregate boundaries. If this proves difficult, you can step back and see if there are more events that might inform things.
Boris and SNAP are often done in parallel, with SNAP as a form of cataloging the conversation that’s happening organically around the Boris diagram.
Challenge: Sometimes we don’t have a clear bounded context at the end of an Event Storming session.
This might mean you’re too zoomed in (you’re only looking at one process or part of a process inside a bounded context) or too zoomed out (you’ve mapped all or a large part of your whole company). Ask the room if this is true, and you can usually zoom in with the room you have at the moment. If you feel like you’re too zoomed in, you may need to come back for a second session with more stakeholders of the surrounding events.
Challenge: We don’t always end up with consensus on the ubiquitous language after a session.
This might be ok as long as the bounded context’s internal engineering and business teams agree on the vocabulary. If there is still fuzziness, you can look for points to collect up all of the nouns and/or verbs and workshop them together (either as a round during the session or with a dedicated session afterwards with the core team).
Challenge: Many folks in the room aren’t engaged, or the conversation is only happening between one or two people.
Ask folks to put away their laptops and phones. Set expectations on involvement early. Run rounds of the Event Storming or Boris where you’re calling specific segments of your audience to layer on their particular perspective if whole-group mobbing is causing some voices to get lost. Remember, if you did the prep work to specifically identify why each person is in the room, you need something from each of them. You can use those identified reasons as a way to call on folks that aren’t participating to add a specific kind of information.
Challenge: It’s difficult to know who all we need for each phase of the process.
See the section on who to invite in the prep work section. Aim for a real or temporarily-imagined balanced team plus folks to represent your stakeholders and consumers.
Challenge: It’s difficult to find someone with facilitation experience to help run a session as the organization scales.
In many ways this is true about any practice, so similar wisdom and optimization can be applied here. See the prep step on identifying facilitators and being deliberate in this process rather than expecting everyone to show up without a specific role.
Also acknowledge that it will take several sessions to go through the “I do, we do, you do” process - more opportunities to facilitate can help mitigate this.
Boris is an activity within the Swift Method.
Swift Method: Event Storming, Boris the Spider and Other Techniques (YouTube video) talk at ExploreDDD 2019 by Shaun Anderson