Using the digital technology capability model: instructions and guidance
he digital technology capability model provides a structured view of the capabilities needed to run a digital organisation. This model is designed to help your department understand what you currently have, how it aligns to your organisation's needs, and where improvements are required.
The steps below explain how to use the model to map and assess your own capabilities.
1. Understand the structure of the model
The model is organised into nine level 1 domains:
- Service applications
- Corporate services
- Integration
- Data and information Management
- Artificial Intelligence
- DevOps
- Foundational technology
- Governance and standards
- Security
Each domain contains level 3 capabilities, with their own definitions and core activities. You can use these artefacts to map your department's technology landscape against these domains and capabilities.
The list of capabilities and their definitions can be found under the Documentation tab on this page's navigation banner.
2. Define the scope of your assessment
Before mapping, clarify:
- which part of the organisation you are assessing, such as a team, business unit or service area
- what should be included, such as applications, services, data platforms, tools and infrastructure
- who needs to contribute information, such as service owners, technical leads and product teams
You should ensure that everyone understands that the assessment is capability-focused, not system-focused.
3. Map department capabilities using the model
Use a hierarchical format to ensure consistency. The required structure is:
Domain → Capability → Application/Service → Technology → Infrastructure
Steps for mapping department capabilities:
Step 3.1: start with the domains
For each of the nine domains, confirm whether your department uses or relies on capabilities within it. If a domain is not relevant, mark it as 'Not in scope' and move on.
Step 3.2: map capabilities
For each relevant domain, review the level 3 capabilities listed in the model. Identify which capabilities your department uses, delivers, or depends on.
Step 3.3: list applications or services
Under each capability, record the applications, digital services or platforms your department uses to deliver that capability.
For example, under 'Case management', you might list Dynamics, Salesforce or an internal system. Under 'API management', you might list Apigee or Azure API management
Step 4: identify technology components
Document the enabling technology behind each application or service. Some examples of these are databases, middleware, workflow engines and integration layers.
Step 3.5: link infrastructure
Capture supporting infrastructure such as hosting environment, storage, compute, networks or cloud services.
This structured mapping ensures every capability has a consistent trail from domain to infrastructure.
Next steps
Identify duplication and fragmentation
Once the mapping is complete, review the outputs to find:
- capabilities delivered by multiple applications.
- applications with overlapping functionality.
- technology stacks that are inconsistent or unnecessarily varied.
- infrastructure components that are duplicated or misaligned.
Ask the following questions:
- you have more applications than are needed to deliver one capability
- you are maintaining outdated or redundant technology
- there are similar services or platforms used in different areas without coordination
- the infrastructure footprint is larger or more complex than required
This helps identify rationalisation opportunities and areas for convergence.
Assess interoperability and integration
Review how well the mapped capabilities work together by:
- identifying where applications rely on point-to-point integrations.
- checking whether APIs, event streaming or shared data platforms are used consistently.
- looking for gaps where integration is manual or missing.
- identifying dependencies that could block future change.
Use the Integration domain as a reference for what good interoperability should look like.
Evaluate capability strength and gaps
Rate each capability based on:
- coverage, to ensure you have tools that support the capability
- quality, to enure the tools are effective and up to date
- alignment, to ensure the capability meet business needs
- efficiency, to ensure the capability is not duplicated or fragmented
- risk, to identify weaknesses in security, resilience or supportability
This will give you a balanced view of maturity and risk across all domains.
Create investment and rationalisation insights
Based on the mapped results, identify:
- applications or technologies that could be retired or consolidated
- capabilities that require investment to meet demand
- areas where standardisation would reduce costs or complexity
- dependencies affecting future transformation
- opportunities to adopt shared platforms or enterprise services
These insights should connect directly to your organisation's strategy and roadmap.
Use visual tools to communicate findings
Clear visuals will support decision-making:
Heat maps
Use colour-coding to show capability strength, duplication, risk, cost or strategic importance.
Application footprint maps
Show how many applications support each capability.
Technology stacks
Present technology layers aligned with capabilities.
Rationalisation targets
Highlight applications recommended for consolidation or retirement.
These visuals will help non-technical stakeholders understand the findings quickly.
Build an actionable roadmap
Translate assessment insights into a capability-driven improvement plan. This should include:
- defined short-term actions, such as removing redundant tools
- setting medium-term targets, such as consolidating platforms or improving interoperability
- setting long-term ambitions, such as moving to event-driven architecture or adopting enterprise AI foundations
- assigning owners, timelines and success measures
The roadmap should show how capability improvements support the organisation's goals.
Remember
Keep the model alive by reviewing it regularly. This should include:
- updating mappings as systems or services change
- reassessing capabilities when new projects begin
- using the model as a reference point for investment decisions, architecture reviews and governance
- appointing an owner for the model