Beyond documenting the current state, how can a context map be used as a strategic planning tool for evolving a system's topology over time — for example, when an organization wants to carve a well-bounded platform out of a legacy 'big ball of mud,' or restructure teams to change how contexts relate?

## Two maps, not one At the strategic level, a context map stops being a passive snapshot of the current system and becomes an instrument for planning change deliberately over a multi-quarter or multi-year horizon. The mechanism for this is to draw two maps rather than one: | Map | What it shows | |---|---| | **As-is** | An as-is map that honestly captures the current topology, including its ugliest parts. | | **Target** | A target map showing the topology the organization wants to exist at some future point. | An undifferentiated legacy system that doesn't cleanly decompose into bounded contexts is conventionally drawn as a single, deliberately messy **'big ball of mud'** box rather than pretending it has internal structure it doesn't have. ## The gap is the backlog The difference between the two maps is not just descriptive; it functions as an executable backlog. Each of these becomes a distinct, sequenceable piece of work: - every edge that needs to change direction; - every context that needs to be split out of the ball of mud; - every ownership boundary that needs to move to a different team. The map then lets a principal engineer or architect reason about ordering — which extractions unblock which others, which changes carry the highest risk, which can be done independently versus which require coordinated cutover. ## Why the two-map approach exists This two-map approach exists because attempting to jump straight from a messy current state to a clean target state in one step is usually both technically and organizationally infeasible: a big-bang rewrite of a legacy system carries enormous risk, while a target architecture that's declared but never connected to a concrete extraction sequence tends to stay aspirational forever. The as-is/target pairing forces the gap to be broken into incremental, individually low-risk steps: 1. extract one well-defined subdomain at a time; 2. put an anti-corruption layer at its boundary with the remaining legacy code so the new context isn't immediately re-coupled to the mud it came from; 3. prove it in production; 4. then repeat for the next subdomain. ## The organizational half The organizational dimension is inseparable from this technical sequencing, which is where the connection to Conway's Law becomes load-bearing rather than incidental. Because a system's architecture tends to mirror the communication structure of the organization that builds it, a target technical topology that isn't paired with a corresponding change in team structure, ownership, and reporting lines tends to drift back toward whatever the org chart naturally produces, regardless of how the target diagram was drawn. In practice this means each technical extraction step in the plan is usually paired with an organizational step: a new context being carved out gets a dedicated owning team, even a small one, rather than remaining a shared responsibility of the legacy team, because a shared-ownership context tends to stay entangled with whatever else that team owns. This deliberate pairing of technical and organizational change is what's meant by the **inverse Conway maneuver** at the strategic level — not a one-time trick applied to a single integration, but a standing discipline of restructuring teams alongside architecture throughout a multi-year migration. ## The trade-off The trade-off in this strategic use is that it requires sustained organizational investment and executive buy-in that a single engineering team can't generate on its own: reorganizing teams, moving reporting lines, and funding a multi-quarter incremental extraction instead of feature work all require the kind of authority a principal engineer typically has to secure from leadership rather than exercise directly. There's also a real risk of the plan going stale exactly like any other context map — a target map drawn once and never revisited against how the extraction is actually progressing becomes just as misleading as a current-state map nobody updates, so the same maintenance discipline applies at the strategic layer too. ## The most visible failure mode The most visible failure mode at this scale is starting an extraction from a big ball of mud without first establishing the anti-corruption boundary, so the newly extracted context immediately absorbs the legacy system's inconsistencies through informal back-channels — the extraction ends up technically 'complete' on paper while the new context is, in practice, still entangled with the mud it was meant to leave behind, defeating the purpose of the migration. ## A concrete, well-known category A concrete, well-known category of this pattern: a company running a decade-old monolithic order-processing system decides to extract a clean Payments bounded context. - The **as-is map** shows Payments logic scattered across three modules inside the monolith with no clear boundary. - The **target map** shows a standalone Payments context, upstream of the remaining monolith via a well-defined event contract, owned by a newly formed Payments team rather than shared with the monolith's maintainers. The roadmap sequences the extraction behind an anti-corruption layer first, migrates one payment flow at a time behind it, and only decommissions the old in-monolith logic once the new context has run in production alongside the old path long enough to build confidence — with the organizational change, standing up the dedicated team, happening before, not after, the technical extraction begins.