Multiple, distinct models emerge and evolve on any large project. This fact of life can be turned to advantage if properly examined.

Context Mapping

Devising a context map has immediate benefits, as everyone comes to have a shared, realistic view of what is going on: Which parts of the model are shared by whom, the nature of dependencies between teams, and the scope of applicability of distinct models. Explicitly named bounded contexts sharpen team language so that design discussions become more concise and less ambiguous.

We work with your developers, domain experts and team leaders, review code and design documents to identify contexts in your project and those you interact with. With this map in hand, we will have flagged hotspots of two kinds: ill-defined contexts, and contexts that are defined, but do not support project objectives.

Sharpening Fuzzy Boundaries and Relationships

A context map always should reflect our best understanding of the current reality. This means that it will not usually look exactly the way you would like the project to run. In fact, the initial context map on many projects reveals areas of ambiguity, where two or more models are being applied to the same module, or where two teams whose work needs to integrate are not appropriately coordinated.

These are parts of the system where design integrity is already in jeopardy and where developers are probably working at cross purposes without even knowing it. Consequences of such confusion range from a loss of productivity, as developers step on each other’s work and face integrations far more difficult than expected, all the way to data corruption in the running software, as different application modules use the same objects and data tables to store subtly different information.

This must be corrected in order for your project to get traction.

Working with team leaders in the affected areas will lead to specific recommendations for newly clarified context boundaries, redesign / refactoring targets to sharpen the new boundaries, and development process changes needed to maintain the integrity of your models.

Steering Toward Your Objectives

After creating a context map and resolving the ambiguities by selective reorganization, you have a rational and shared view of the use of models on the project. Now you can set a strategy.

Working with project leaders, we take a close look at boundaries and relationships between subsystems and the teams that work on them, particularly those which are not serving the project’s goals well. Perhaps you need smoother integration in a part of the system that is currently chopped up. Perhaps you are incurring integration overhead on parts of the system that don’t really need it. Or maybe two teams are duplicating effort, or a team is being left in the lurch. There are many possible scenarios.

The clarity of a context map allows you to begin to make conscious, pragmatic decisions, and plot a course toward more effective organization of design work. We can advise on these decisions and then coach teams through the transition.