Instantiating Business Capabilities: From Model to Strategic Dashboard

Having a capability map is step one. Instantiating it — filling it with concrete data: maturity, costs, applications, performance — is what transforms it into a decision-making tool. Without data, your capability map is a nice poster on the architect's wall. With data, it's a strategic dashboard the executive committee consults before making trade-offs.

Instantiation is the step that separates decorative business architecture from useful business architecture. Here are the three instantiations I always perform, how I cross them to derive investment priorities, and how I keep them alive over time.

From map to strategic dashboard

A blank capability map answers a single question: what does the organization know how to do? Useful, but not enough to decide. Instantiating means overlaying on that map layers of information that answer executives' real questions: where are we fragile? where do we overspend? where to invest first?

Each instantiation layer is a factual answer to one of those questions. And because everything ties back to the same stable map, these layers cross and accumulate over time, turning a one-off deliverable into a permanent steering repository.

Instantiation 1 — maturity assessment

The first instantiation I always perform is maturity assessment. For each capability, I work with the business to evaluate the current level on a simple scale: Initial, Repeatable, Defined, Managed, Optimized. It's simplified CMMI, adapted to the context and deliberately kept light.

The result is a heatmap that immediately shows where the organization is strong and where it's fragile. This simple coloring often triggers realizations: a capability deemed strategic but rated 'Initial' is an alarm signal no financial table revealed.

Instantiation 2 — application mapping

The second instantiation is application mapping: which applications support which capability? This exercise reveals redundancies and blind spots. Three CRMs for the same 'Manage Customer Relationships' capability, or conversely a critical capability like 'Drive Compliance' running on a shared Excel file.

These discoveries change investment priorities and feed directly into application rationalization. The capabilities × applications matrix becomes the bridge between business architecture and IT architecture: you stop reasoning 'by application' and start reasoning 'by capability served', which finally makes trade-offs objective.

Instantiation 3 — strategic alignment

The third instantiation is strategic alignment. You cross the capability map with the company's strategic axes: which capabilities are critical for the 3-year strategy? You assign each capability a strategic importance, then confront it with its real maturity.

This layer links business architecture to corporate strategy. A capability can be mature but non-strategic (a stabilization candidate) or strategic but immature (an investment candidate). It's this crossing that steers decisions, not maturity alone.

Crossing importance and maturity: the investment matrix

The real power of instantiation appears when you cross the layers. The gap between strategic importance and current maturity directly gives the list of priority investments:

• critical and immature capability: absolute investment priority;
• critical and mature capability: protect and evolve;
• secondary and immature capability: leave as is;
• secondary and over-invested capability: simplification candidate.

This matrix is a list the executive committee grasps immediately, because it talks neither of applications nor technologies, but of what the company knows how to do and what it must do better. It's the heart of capability-based planning.

Keeping instantiation alive

Instantiation isn't a one-shot exercise. Data changes, priorities evolve, applications get renewed. I recommend a semi-annual review of maturity assessments and an annual refresh of application mapping, ideally automated through the EA tool's connectors (CMDB, PPM).

It's this regular maintenance that moves the capability map from 'consultant deliverable' status to permanent steering tool. A frozen instantiation ages as badly as an abandoned application map: the value is in freshness as much as in content.

What I take from the field

Instantiating a capability map is what brings it to life. Three layers are enough to turn a poster into a dashboard: maturity to see weaknesses, application mapping to see redundancies, strategic alignment to see priorities.

The secret is in the crossing: it's the gap between what matters and what works that points to where to invest. And that objectification is what finally depoliticizes budget arbitrations.