Capability Design and Development: From Mapping to Context-Aware Delivery

Capability mapping has become standard practice.

Most organisations of any size have attempted some version of it: workshops to identify capabilities, models to structure them, heat maps to assess them, matrices to prioritise them.

And yet, capability maps rarely change anything.

The map sits in a repository. Executives reference it occasionally. Architects consult it dutifully. But the organisation doesn’t actually become more capable.

Why? Because mapping isn’t making. And the discipline of capability development (actually designing and building organisational capabilities) remains surprisingly underdeveloped in practice, despite rigorous academic work that shows the way forward.

What Is a Capability, Really?

Before we can develop capabilities, we need a clear definition. The research from the EU CaaS (Capability as a Service) project offers a useful one:

A capability is the ability and capacity that enables an enterprise to achieve a business goal in a certain context.

Three elements matter here:

Ability refers to competence: the skills, knowledge, and talent the organisation possesses.

Capacity refers to resources: the money, time, personnel, and tools available.

Context is the crucial addition. A capability isn’t absolute; it exists in relation to a specific situation. The organisation that can issue mortgage loans effectively in Sweden may not be able to do the same in Latvia without significant adaptation.

This context-dependency is why traditional capability mapping falls short. Static maps assume capabilities exist independently of context. But in reality, what you can do depends heavily on where, when, and for whom you’re doing it.

The Problem with Mapping Alone

Capability maps answer the question: “What does this organisation do?”

That’s useful context. But it doesn’t answer the questions that actually matter:

What capabilities do we need that we don’t have?
How do we build new capabilities deliberately rather than accidentally?
What does it take to make an existing capability genuinely better?
How do we ensure capabilities work across different contexts?
How do capabilities adapt when context changes?

Traditional capability mapping treats capabilities as static objects to be catalogued. Capability-Driven Development (CDD) treats them as dynamic assets that must be designed, built, and continuously adjusted.

The shift is fundamental: from nouns to verbs, from states to processes.

Capability-Driven Development

The CDD methodology, developed through European research collaboration, provides a structured approach to capability management that goes far beyond mapping. It integrates:

Business and IT Development

Capabilities sit at the intersection of business strategy and technology implementation. CDD provides methods for ensuring alignment between what the business needs and what technology delivers.

Design Time and Runtime

Here’s where CDD differs most from traditional approaches. It’s not enough to design a capability and deploy it. Capabilities must be able to adjust at runtime, adapting to context changes without requiring redesign cycles.

Context Modelling

Context isn’t just background noise. CDD includes explicit methods for modelling the contexts in which capabilities operate: internal contexts (organisational changes, policy shifts) and external contexts (market conditions, regulatory requirements, competitive dynamics).

Adjustment Mechanisms

Perhaps most importantly, CDD provides frameworks for how capabilities should adjust when context changes. This is the difference between a capability that works today and a capability that continues to work as the world changes.

The Capability Development Canvas

Drawing on both CDD principles and practical experience, I use a structured canvas for capability development that covers five dimensions:

1. Purpose and Context

Start with why and where. What strategic objective does this capability serve? What value does it create, for whom, and in what contexts?

The contexts matter as much as the purpose. A capability designed for one context may fail in another. Understanding the range of contexts the capability must serve shapes every subsequent design decision.

2. Current State Assessment

Be honest about where you are. Not just maturity scores, but concrete assessment of what works, what doesn’t, and why. Where are the bottlenecks? What’s missing? What’s broken? And critically: in which contexts does the current capability work, and in which does it fail?

3. Target State Design

Design the capability you need, considering the full range of contexts it must serve. This is where the CDD concept of capability patterns becomes useful: recurring configurations of goals, contexts, and resources that can be reused and adapted.

The target state isn’t just “better”. It’s a coherent design that addresses root causes and builds in adaptability.

4. Context-Aware Adjustment

This is the element most traditional approaches miss entirely. How will this capability detect context changes? How will it adjust? What parameters can vary, and within what bounds?

Capabilities that can’t adjust are capabilities that will become obsolete. The design should include explicit mechanisms for sensing context and adapting delivery.

5. Operating Model Integration

Capabilities don’t exist in isolation. They interact with other capabilities, governance structures, and operating model choices. How does this capability fit into the broader system? What organisational adoption is required?

The Capability Management Life Cycle

CDD research identifies a full life cycle for capability management:

Capability Design: Creating capability models that capture goals, context, resources, and delivery patterns.

Capability Delivery: Implementing the capability through business processes, information systems, and organisational structures.

Capability Adjustment: Modifying capability behaviour based on context changes, either automatically or through managed processes.

Capability Evaluation: Assessing capability performance and identifying improvement opportunities.

This cyclical view is essential. Capabilities aren’t projects with end dates. They’re ongoing organisational commitments that must be managed continuously.

What Changes

When organisations shift from capability mapping to capability development, several things change:

Investment conversations become concrete. Instead of “we need to improve our data analytics capability,” you have a development plan with context models, adjustment mechanisms, and success measures.

Architecture becomes actionable. The capability model isn’t just a reference. It’s a backlog of development work. Every capability has a current state, target state, context considerations, and development pathway.

Transformation becomes measurable. You can track capability development progress independent of project delivery. Are the capabilities actually improving? Are they performing across required contexts?

Adaptability becomes designed. Rather than hoping capabilities will evolve appropriately, you explicitly design how they should respond to change.

The Digital Enterprise Imperative

The CDD research emerged from studying digital enterprises: organisations whose business models depend fundamentally on information systems and that operate in volatile, interconnected environments.

For digital enterprises, capability thinking isn’t optional. These organisations face:

Context volatility: Business environments that change rapidly and unpredictably
Integration complexity: Ecosystems of partners, platforms, and services that must work together
Runtime demands: Requirements that emerge at runtime, not design time
Scalability pressures: Capabilities that must work at vastly different scales

Traditional approaches (design, build, deploy, and occasionally update) can’t keep pace. Capabilities must be designed for continuous adaptation.

Connecting to My Practice

I’ve integrated these concepts into how I approach architecture work:

When I build capability models, I include context dimensions and adjustment parameters, not just hierarchies and descriptions.

When I design transformation roadmaps, I plan for capability development as a continuous process, not a one-time project.

When I build tools like the Soaring Wings platform, I implement structures that support context modelling and capability tracking over time.

The CDD research provides rigorous foundations. The challenge is making these concepts accessible and practical for organisations that need to transform today.

The Bottom Line

Capability mapping asks: “What do we do?”

Capability development asks: “What should we be able to do, in what contexts, with what adaptability, and how do we get there?”

The organisations that create genuine value don’t just understand their capabilities. They deliberately design and build capabilities that work across contexts and adapt as those contexts change.

That’s not just good architecture. That’s how organisations achieve escape velocity, by building engines that create lift regardless of the terrain they’re flying over.

References

Sandkuhl, K. & Stirna, J. (Eds.) (2018). Capability Management in Digital Enterprises. Springer International Publishing.
Stirna, J. & Sandkuhl, K. (2018). Enterprise Modelling: Establishing the Fundament for Capability Management. In Capability Management in Digital Enterprises (pp. 85-99). Springer.
Grabis, J., Zdravkovic, J., & Stirna, J. (2018). Overview of Capability-Driven Development Methodology. In Capability Management in Digital Enterprises (pp. 59-84). Springer.
Henkel, M., Zdravkovic, J., Valverde, F., & Pastor, O. (2018). Capability Design with CDD. In Capability Management in Digital Enterprises (pp. 101-116). Springer.

The Capability-Driven Development methodology was developed through the EC FP7 CaaS (Capability as a Service) project consortium.