Context Mapping on a Business Grid

Alberto Brandolini • Focus On • Apr 21, 2020

If your organisation is active on multiple business channels or business lines, mapping the bounded contexts might turn out a little more complicated.

When writing the software for Avanscoperta, we often categorised different things as Bounded Contexts like "Training" versus "Consulting" versus "Planning" versus "Finance". After a while, the whole thing started to ache, since there was some planning in consulting and some in public training too, but... not exactly the same planning.

Make business lines visible

We acknowledged that we needed a more sophisticated structure, something that treated business lines and bounded contexts differently. So the first step was to find a way to visualise the different business lines.

Since we've been exploring them already with EventStorming it made sense to use horizontal stripes as a graphical representation. Here is the result after adding some arbitrary colours.

The current open business lines for avanscoperta, circa 2019.

If you are surprised that such a small company has so many business lines open, well... I am surprised too!
A few of these business lines aren't actually supposed to make any money. For example, Sponsorships is intended to be a financial loss, but nevertheless, it has the complexity of a real business line, including budgeting constraints, a design phase for materials, planning, communication, logistics, delivery and a final evaluation phase too.

Make business phases visible

The second step is to provide a little more background structure to our context map.
After seeing a few EventStorming outcomes, it becomes natural to look for some sort of phases in the different business lines.

I am not sure this thing deserves a name, but we might call it business grid.

I laid down a plausible sequence of phases (Strategy, Product Design, Planning, Sales, Delivery, Billing, and Financial Analysis) and placed them on top of the swim-lanes.
The phases aren't mandatory, and their order can be debatable too. For example, planning happens usually before sales in public training, while in consulting is the other way round.

Being precise isn't the goal here, the main goal is to have a grid that could be used as a background for our context map.

Add your context map

And here is a possible map, after we started putting bounded contexts on top of our business grid. The map isn't complete but it's already showing something interesting.

The shape of the many bounded contexts after placing them on top of the business grid.

Public Training is clearly the most mature business line in our scenario, some bounded contexts are really specific to this business line, like Date Picking, and Ticketing and Discounts.
Some Bounded Contexts are shared between different business lines. Content design and Pricing have very similar concerns for private and public training, often it can be the same product, just with a different execution-style. Certificates used to be related to public dates only, but it's expanding to private classes too.
Billing looks like a very generic context here. Every single business line making money has billing concern, though maybe not at the same level of complexity. Same goes for Marketing and Travel and Logistics. In general, generic tend to look bigger in this specific visualisation style.

Putting everything together

There's a few things I really like about this format.

Reading a single business line left to right is matching the emerging EventStorming narrative, and the Value Delivery Network, making this representation more revealing also without a large number of parallel business lines.
When the complexity of the business scales up with multiple business lines, maybe on top of shared platform services, this format helps to keep the overall picture under control and managing corner cases like having a planning bounded context in public training which is completely unrelated to a planning bounded context in software delivery.
It gives me the background for more precisely defined bounded contexts, like specialised models serving a very specific purpose. I.e. Date Picking intended as "suggesting the perfect date for a public training" can have a very specific and dedicated model which is only loosely coupled to the generic problem of planning.