Before you even start to think about how a modern system might be architected, you must know the business needs that the system needs to support. The software exists to support real-world events that occur in the daily operations of a business. There is no point in creating software that doesn’t line up with what happens in the physical world.
When it comes to understanding software, it’s helpful to think in terms of the series of events that occur in the business, using a shared language that bridges the business and technical contexts. These events drive architectural aspects of the system design: domains, bounded contexts, and services of a system.
For example, let’s say you want to model the business process around designing a self-serve kiosk at a fast-food restaurant. You might identify events around creating an order for each person; adding the type of burger, sides, and drink to that order; queuing up the multiple orders received for the kitchen; and notifying the customer when their order is ready for pickup. Analyzing the domain at this level makes it possible to model new flows and ideas, synthesize knowledge, and facilitate active group participation without conflict in order to ideate the next generation of a software system.
A successful event storm will produce the following outcomes:
Attempting to model the entire notional architecture often results in analysis paralysis. Most likely, the event storm has revealed what we call thin slices: starting points for rearchitecting the system that achieve a partial, yet tangible, modernization outcome. We like to differentiate these thin slices as system-level outcomes, versus something like a minimum viable product (MVP), which is a related concept at the product level.
We use Boris to model the interactions between bounded contexts, identified in the event storm, within a complex system to reveal the notional target system architecture within the thin slice. At this level, we’re trying to:
For example, a thin slice for designing a self-serve kiosk at a fast-food restaurant might look like the ability to create an order with all the selected products by the diner that the kitchen sees and can complete. Boris identifies how the order and kitchen-bounded contexts will negotiate the flow of information between these bounded contexts.
Concurrent to Boris, SNAP is used to quickly document the services needed to implement the notional architecture discovered by Boris. Information is often grouped into APIs, data, pub/sub, external systems/UI, stories, and risks. The key artifact is a poster-size sticky paper on a conference room wall or similar from a digital workspace, with one SNAP per node or service depicted on Boris.
A successful Boris and SNAP will produce the following outcomes:
Once completed, a series of successful Swift workshops will produce the following outcomes:
In our experience after working with hundreds of organizations, Swift is a powerful technique that makes the modernization journey more enjoyable, manageable, and effective. We have additional posts featuring tips and examples of how developers, architects, and product managers/owners collaborate throughout Swift’s different stages of modernizing a system.
Breaking Down a Monolith into Microservices
Event Storming | VMware Tanzu Developer Center
Boris | VMware Tanzu Developer Center