Technology Capability Models

Research Question

What established and emerging IT capability models define a complete, multi-level set of technical capabilities - such as authentication, networking, Application Programming Interface (API) gateways, and data storage - and which model or combination of models best supports: (a) designing new and existing solutions without tying to specific implementation details, and (b) assessing capability maturity against a standardised framework to identify where investment is needed?

Supporting questions:

• What multi-level capability taxonomy models currently exist across both traditional architecture frameworks and modern engineering-focused approaches?
• What are the strengths and weaknesses of each model for the purposes of abstract capability design and maturity assessment?
• How do these models handle the traceability link from business functions down through IT services to technical capabilities?
• How does ServiceNow's Common Service Data Model (CSDM) relate to or complement these capability models?
• Which single model or which combination would best serve as a foundation for a capability map that is implementation-agnostic and assessable for maturity?

Findings

(Populated from Section 6 Synthesis above.)

Executive Summary

[inference] No single surveyed public framework can serve as both the enterprise-wide technical capability taxonomy and the maturity model, so the strongest answer is a layered stack that combines a generic taxonomy backbone, a maturity overlay, and an operational traceability model. Sources: TOGAF Standard (10th Edition, 2022) - The Open Group; ivi.ie; cmmiinstitute.com.

[inference] The most defensible composition is a TOGAF-style backbone plus IT-CMF plus CSDM, because TOGAF contributes reusable implementation-agnostic structure, IT-CMF contributes maturity mechanics, and prior repository work shows that CSDM contributes the operational traceability layers needed to anchor the model in ServiceNow. Sources: TOGAF Standard (10th Edition, 2022) - The Open Group; www.opengroup.org; ivi.ie; github.com; github.com.

[inference] Sector, security, and engineering frameworks such as BIAN, TM Forum TAM, SABSA, NIST CSF 2.0, ZTA, DORA, Team Topologies, Wardley Mapping, and the cloud well-architected frameworks should improve or specialise the map rather than replace the enterprise-wide backbone. Sources: bian.org; www.tmforum.org; sabsa.org; csrc.nist.gov; csrc.nist.gov; dora.dev; teamtopologies.com; learnwardleymapping.com; docs.aws.amazon.com; Azure Well-Architected Framework (2024) - Microsoft; Google Cloud Architecture Framework (2024) - Google.

Key Findings

1. [inference][high] No surveyed public framework is simultaneously a modern enterprise-wide technical capability taxonomy and a robust maturity model, so organisations that need both outcomes must combine at least one classification framework with at least one maturity overlay. Sources: TOGAF Standard (10th Edition, 2022) - The Open Group; ivi.ie; cmmiinstitute.com.
2. [inference][medium] TOGAF's Technical Reference Model and Integrated Information Infrastructure Reference Model are the best general-purpose public backbone in the set because they provide reusable cross-industry structural categories without binding the capability map to specific vendors or implementations. Sources: TOGAF Standard (10th Edition, 2022) - The Open Group; www.opengroup.org.
3. [inference][high] IT-CMF is the strongest enterprise-level maturity companion in the survey because IVI explicitly positions it as a 37-capability framework with maturity profiles, assessments, and improvement roadmaps that complement other domain-specific frameworks rather than replace them. Source: ivi.ie.
4. [fact][medium] DoDAF, NAF, BIAN, and TM Forum TAM all provide meaningful multi-level decomposition or traceability, but each does so inside a bounded defence, banking, or telecom context rather than as a neutral enterprise technology stack. Sources: dodcio.defense.gov; fachglossar.platinus.at; bian.org; www.tmforum.org.
5. [fact][high] SABSA, NIST CSF 2.0, and ZTA are valuable security overlays because they describe security attributes, outcomes, or logical security components, but they do not attempt to describe the full technical capability stack for the rest of enterprise IT. Sources: sabsa.org; csrc.nist.gov; csrc.nist.gov.
6. [fact][high] Team Topologies, DORA, Wardley Mapping, and the well-architected frameworks contribute team-design, performance, strategy, or review discipline rather than a canonical enterprise capability taxonomy, so they should challenge and improve the map instead of defining it. Sources: teamtopologies.com; dora.dev; learnwardleymapping.com; docs.aws.amazon.com; Azure Well-Architected Framework (2024) - Microsoft; Google Cloud Architecture Framework (2024) - Google.
7. [inference][high] CSDM should be used as the operational representation layer for the capability map, with shared technical capabilities anchored first to Technical Services and then traced down to Configuration Items, because prior repository work shows that CSDM is strong on traceability but not on capability definition. Sources: github.com; github.com.
8. [inference][high] The most defensible rollout path is to stabilise CSDM ownership and service layers first, define a small implementation-agnostic enterprise capability backbone next, map Technical Services and Application Services onto it, and only then apply IT-CMF and targeted overlays for maturity and design review. Sources: github.com; github.com; ivi.ie.

Assumptions

• [assumption] TM Forum TAM remains application-centric in the current public standard even though the official TAM detail page was inaccessible in this environment. Justification: accessible public explainers and official TM Forum references consistently describe eTOM as process architecture and TAM as the application architecture companion. Sources: www.tmforum.org; www.ntt-review.jp; www.telecom-expertise.com.
• [assumption] SABSA's current public executive-summary content still reflects the six-layer, business-attribute-driven structure described in accessible secondary sources. Justification: direct fetch of the official page returned 403, but public SABSA descriptions were consistent and aligned with long-standing SABSA structure. Sources: sabsa.org; en.wikipedia.org; davidlynas.com.
• [assumption] A local enterprise capability map will need extension for modern platform areas such as internal developer platforms, event streaming, and artificial intelligence operations because the generic public frameworks do not normalise those areas consistently. Justification: the most general frameworks are reference models or overlays rather than contemporary exhaustive technical libraries. Sources: TOGAF Standard (10th Edition, 2022) - The Open Group; teamtopologies.com; docs.aws.amazon.com.

Analysis

• [inference] The evidence points to a layered architecture because the frameworks answer different questions: TOGAF and sector models classify capability structure, IT-CMF and CMMI score maturity, CSDM provides traceability, and DORA or Team Topologies shape how capabilities are operated. Sources: TOGAF Standard (10th Edition, 2022) - The Open Group; ivi.ie; cmmiinstitute.com; github.com; dora.dev; teamtopologies.com.
• [inference] The main trade-off is breadth versus specificity: general frameworks are reusable but coarse, while sector frameworks are precise but hard to generalise beyond their native industries. Sources: TOGAF Standard (10th Edition, 2022) - The Open Group; bian.org; www.tmforum.org; dodcio.defense.gov.
• [inference] The recommendation therefore favours composition over purity: use one backbone for stable capability names, one operational model for traceability, and targeted overlays for risk, design quality, or engineering performance. Sources: TOGAF Standard (10th Edition, 2022) - The Open Group; ivi.ie; github.com; csrc.nist.gov; dora.dev; docs.aws.amazon.com.

Risks, Gaps, and Uncertainties

• [fact] Official SABSA and TM Forum detail pages were partially inaccessible from this environment, so the conclusions on those frameworks rest on mixed official metadata and public supporting summaries rather than on fully fetched primary text. Sources: sabsa.org; www.tmforum.org.
• [inference] TOGAF's public material is sufficient to justify its role as the generic backbone, but a production rollout would still need licensed or internal detail to define the exact level-2 and level-3 capability families. Sources: TOGAF Standard (10th Edition, 2022) - The Open Group; www.opengroup.org.
• [inference] The recommendation does not eliminate local design work, because modern platform capabilities are not normalised consistently across the surveyed public frameworks. Sources: TOGAF Standard (10th Edition, 2022) - The Open Group; teamtopologies.com; docs.aws.amazon.com.

Open Questions

• Which concrete level-2 and level-3 capability families should be standardised first for this repository's likely enterprise context: identity, networking, integration, observability, or data?
• What is the cleanest way to attach IT-CMF maturity scoring to individual Technical Services in CSDM without creating duplicate governance structures?
• How much local extension is needed to represent platform engineering, internal developer platform, and artificial intelligence operations capabilities cleanly on top of a TOGAF-style backbone?

sources

• [x] TOGAF Standard (10th Edition, 2022) - The Open Group — specifically the Architecture Reference Models chapter; primary source for TOGAF Technical Reference Model (TRM) and Integrated Information Infrastructure Reference Model (III-RM)
• [x] SABSA Framework and Architecture - The SABSA Institute — specifically the Business Attributes Profile and the SABSA Matrix; primary source for SABSA capability layers
• [x] BIAN Service Landscape (v12, 2023) - Banking Industry Architecture Network — the service domain taxonomy as a banking-specific technical capability model
• [x] TM Forum Frameworx - TM Forum — specifically the Business Process Framework (eTOM) and Application Framework (TAM) capability taxonomies
• [x] NIST SP 800-207 (2020) - "Zero Trust Architecture" - NIST — ZTA capability components as a modern security-layer capability model
• [x] NIST Cybersecurity Framework (CSF) 2.0 (2024) - NIST — capability function taxonomy (Govern, Identify, Protect, Detect, Respond, Recover)
• [x] DoDAF Architecture Framework (v2.02) - US Department of Defense — specifically capability viewpoints (CV-1 through CV-7)
• [x] NAF v4 (2018) - NATO Architecture Framework — capability taxonomy and Consultation, Command and Control (C3) Taxonomy
• [x] IT-CMF (IT Capability Maturity Framework) - Innovation Value Institute (IVI) — the 36-capability taxonomy and maturity model
• [x] CMMI v2.0 (2018) - CMMI Institute — capability area and practice area structure as a maturity-linked capability model
• [x] Wardley Mapping — Simon Wardley (2016-2024) — capability evolution model from genesis to commodity
• [x] Wardley Mapping — Medium series
• [x] "Team Topologies" - Skelton, M. & Pais, M. (2019) - IT Revolution Press - specifically platform team capability design and the interaction modes
• [x] DORA (DevOps Research and Assessment) State of DevOps Reports (2019-2024) - Google/DORA — technical and process capability clusters and their performance linkages
• [x] AWS Well-Architected Framework (2024) - Amazon Web Services — six pillars as a cloud-native technical capability taxonomy
• [x] Azure Well-Architected Framework (2024) - Microsoft — five pillars and design area taxonomy
• [x] Google Cloud Architecture Framework (2024) - Google — system design principles as capability taxonomy
• [x] Gartner IT Score - Gartner — IT functional capability model and maturity scoring (note: marketing from Gartner; treat as low-confidence for structural detail but useful for industry adoption evidence)
• [x] Prior completed research: 2026-03-08-servicenow-csdm-data-modelling
• [x] Prior completed research: 2026-03-08-servicenow-platform-strategy