Capability-mapping and context-mapping

Context mapping solves at least two issues.

The first one is conceptual integrity, which Frederick Brooks, the author of The Mythical Man-Month, considers the main thing to keep in mind while designing and maintaining any system. Every developer is aware of each higher-level part and realizes what it basically does. Every developer has a visual image of applicability boundaries of the model he or she is working with. One can have a clue what’s applicable in other models. And, finally, we can see how the contexts are connected with each other.

The second one is managerial.Usually one team is engaged in one or more contexts. Really big contexts that require more than one team are seldom. So, generally, teams are aligned along contexts. Thus, context mapping helps to visualize the relationships between teams, which results in context relationships. Would one context’s API adjust to another context’s API? Would one context implement a functionality that is needed by another? Would the relationships between them be a Customer/Supplier? Or one of them would have to become a Conformist? All these questions reflects a political environment and, as a result, an organizational relationships in a company. And the corresponding answers should be discovered — the earlier, the better.

Capability mapping + context-mapping = winning combo

The are at least two issues where capability mapping complements context-mapping.

The first one is relationships. While context mapping gives an idea of organizational relationships, it won’t tell how these contexts communicate with each other. Capability mapping succeeded in this one.

The second issue is probably a result of wrong comprehension of the Bounded Context notion. I’ve always found that the fact that bounded contexts do not inhabit the concept of nesting limits my overall system view, my higher-level understanding of a system. Bounded contexts are not portrayed nested probably because context mapping stresses the organizational structure scheme, where one team is an undividable item. Or maybe it’s a result of bounded contexts being understood as a physical boundary, I don’t know. Anyway, it’s hard to comprehend the way that an enterprise operates using only context mapping.

Meanwhile, capability mapping services can be nested into each other. It’s like a more coarse-grained capability consists of more fine-grained capabilities, with clear communication scheme.

From the other side, I guess the way that context mapping is implemented was chosen deliberately. Context-mapping is not overloaded, it looks fine. It represents relationships between teams involved in different contexts — and it does it well. Let it be its responsibility, and let business-capability mapping have exclusively an operational focus.

Capability-mapping and context-mapping was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.