Capabilities Inventory and Attributes

About This Inventory

The Capabilities Inventory governs the enterprise capability map — the structured, hierarchical taxonomy of every distinct area of organizational ability that the enterprise performs, intends to perform, or has decided to exit. A Capability is not a process, not an application, and not a technology: it is an outcome-oriented description of what the enterprise does or must do, independent of who currently does it, which system supports it, or how it is organized today. The inventory records each Capability as a governed Noun Instance with a unique Semantic ID, a full hierarchical path from root to leaf, a description precise enough to distinguish it from adjacent Capabilities, and the full set of governance attributes needed to assess its maturity, prioritize investment, identify who performs the work, and connect the Capability to the rest of the Enterprise Model.

What Counts as a Capability

A Capability describes what the enterprise can do — an outcome-oriented ability that produces value or supports the enterprise’s mission. Capabilities are stable across organizational changes, process redesigns, and technology replacements. The capability “Member Enrollment” exists today, will exist five years from now, and would still exist if every system, process, and organizational unit supporting it were replaced. That stability is what makes Capabilities the natural anchor for enterprise architecture, portfolio management, and strategic planning.

In the IF4IT model, every node in the Capability Hierarchy is treated as a Capability. The strict distinction between Capability and Function found in some frameworks — where Capability describes what the enterprise can do (including latent abilities) and Function describes what the enterprise actually does (organized activity) — is collapsed in this framework into a single concept. The pragmatic reality is that a Function such as “Process Claims” can be restated as a Capability such as “Claims Processing” with no loss of information; the underlying business reality is the same, and only the vantage point has shifted from activity-oriented to outcome-oriented. For the overwhelming majority of inventory nodes, the two forms map one-to-one. Enterprises that wish to descend further into function-level or sub-function-level detail are free to do so; function-level nodes are simply deeper-level Capabilities in this framework.

The strict distinction does earn its keep in three narrow cases — latent capabilities (abilities the enterprise possesses but has not yet exercised), aspirational capabilities (target-state abilities the enterprise is building toward), and decayed capabilities (abilities the enterprise formally retains but where competence has eroded). For these cases, the Capability framing is the correct one: the inventory captures the ability whether or not corresponding activity is currently being performed. The Lifecycle Status, Assessed Maturity, and other governance attributes provide the means to model the difference between a vibrant capability, a latent one, an aspirational one, and a decayed one — without requiring the model to split into separate Capability and Function constructs.

The Recommended Top-Level Decomposition

The IF4IT recommends a three-branch top-level decomposition of the Capability Hierarchy, rooted at the enterprise itself. Beneath the root, three Level 1 branches partition the Capability space along the dimensions that matter most for strategic and architectural analysis:

• Industry-Specific Capabilities — abilities that define what kind of enterprise the organization is. They are the abilities that distinguish a healthcare payer from a manufacturer from a university. Without these, the enterprise would not be in its industry at all.

• Core Business Capabilities — abilities every enterprise needs to function regardless of industry. Finance, Human Capital Management, Legal, Procurement, Sales, Marketing, and similar disciplines fall here. They are commodity at the top level — every enterprise has them — but increasingly differentiated as you decompose.

• Information Technology (IT) Capabilities — abilities required to acquire, deliver, operate, and govern the technology that supports both of the above. They are separated rather than merged because IT capabilities have their own governance cadence, their own ownership patterns, and their own strategic considerations.

This three-branch structure works for the vast majority of enterprises. It is a strong default — not a prescription. Enterprises are free to rename, add, merge, or split top-level branches to fit their own structure. Several adaptations are common and reasonable. Pure-IT organizations such as an IT consultancy or a software vendor may collapse the Industry-Specific branch into the IT branch, or rename the Industry-Specific branch to reflect their service portfolio, because the boundary between the two blurs when IT is the industry. Conglomerates with operations in multiple unrelated industries may need multiple Industry-Specific branches, one per business line; the model accommodates this naturally by adding additional Level 1 branches. Government and non-profit organizations may relabel “Core Business” as “Core Operations” or “Core Mission” to reflect a non-commercial orientation; the structure holds while the labels adapt. The principle is that the top-level decomposition should serve the enterprise’s analytical needs, not the other way around.

Hierarchy Depth

The recommended baseline hierarchy depth is Level 0 through Level 4, with Level 4 typically being leaf nodes. Level 0 is the root (the enterprise itself). Levels 1 through 4 progressively decompose Capabilities from broad organizational domains down to specific operational sub-capabilities. The recommended baseline supports the analytical depth most enterprises need without producing taxonomies that are too granular to govern.

The framework imposes no hard depth limit. Enterprises that need to descend further into function-level or sub-function-level detail — common in regulated industries, in operationally complex domains, or in mature inventories that have evolved beyond the baseline — are free to extend the hierarchy as deep as their analytical needs require. The attributes, hierarchy structure, Semantic ID conventions, and Hierarchy Identifier scheme all extend naturally to any depth. Conversely, enterprises with a smaller operational footprint may stop at Level 2 or Level 3 if deeper decomposition adds no governance value. Depth is a modeling decision driven by what the enterprise needs to analyze, not by an external constraint.

Document Organization

This document is organized into attribute categories, each forming its own subsection. Each subsection contains one part with an attribute table. The attribute table has three columns: Attribute Name, Maturity, and Description and Notes. The Attribute Name column uses bold text in Title Case — multi-value attributes append [Multi-Value] below or beside the name, and hierarchical attributes append [Hierarchical]. The Maturity column contains one of three values: Crawl (minimum viable attributes without which the inventory cannot function as a governance instrument), Walk (attributes that add the rigor needed for assessment, rationalization, and financial analysis), or Run (attributes that enable advanced analytics, AI-assisted portfolio intelligence, and cross-inventory derivation). The Description and Notes column is structured into labeled subsections: Description — what the attribute captures; Benefit(s) — the governance value it produces; Source — whether the value is Manual, Derived from another inventory, or Calculated; Examples — concrete sample values where format or convention aids understanding; and Notes — implementation guidance, valid values, or connections to other inventories, omitted when nothing meaningful to add. The attributes shown represent the IF4IT’s current best thinking for governing the Capabilities Inventory — a suggested baseline, not a complete enumeration. Practitioners will encounter attributes in their own implementations that are not listed here and are encouraged to add them. No attribute in this document is mandatory.

General Governance Principles

For the general inventory governance principles that apply to this inventory — including semantic identifier conventions, data quality standards, owner accountability, lifecycle management, AI-assisted population, and the connection to the Enterprise Model — refer to the IF4IT Enterprise Inventory Management Best Practices document.

Customization

Every attribute in this document is a recommendation — not a mandate. Enterprises are explicitly encouraged to add attributes specific to their context, rename attributes to match their existing vocabulary, adjust valid value sets to match their organizational standards, collapse or expand attribute categories for their tooling, and sequence Crawl/Walk/Run adoption differently based on their priorities. Three things are discouraged: removing foundational Crawl attributes entirely, since portfolio governance consistently fails without them; ignoring the Source designation for Calculated and Derived attributes, since manually entering system-populated values creates data quality problems that compound over time; and abandoning the Semantic ID convention, since it is the connective tissue that makes cross-inventory traversal and AI-assisted analysis possible in the Enterprise Model.

Tooling Guidance

The Crawl/Walk/Run maturity tagging in this document applies not only to which attributes to collect but also to what tooling is appropriate at each stage. At Crawl maturity, a well-structured shared spreadsheet — Google Sheets, Microsoft Excel shared via SharePoint, or equivalent — is a completely acceptable starting point for this inventory. A spreadsheet with the Crawl-tagged attributes populated for every known Capability is more valuable than a sophisticated inventory management tool with no data in it. At Walk maturity, a lightweight database, Airtable, Notion, or a basic configuration item structure within an ITSM platform provides the query, filter, and reporting capabilities that spreadsheets make difficult at scale. At Run maturity, a dedicated inventory platform, a ServiceNow ITAM or APM module, or a custom data store integrated with the Enterprise Model supports full API connectivity, automated derivation of calculated attributes, and real-time cross-inventory relationship traversal. Governance discipline and data quality matter far more than tooling sophistication — particularly at Crawl and Walk maturity.

The Enterprise Model

This inventory is a component of the Enterprise Model: every record in it, and every attribute of every record, contributes to the enterprise intelligence platform that connects every IT Management discipline — APM, TPM, Enterprise Architecture, IT Operating Environments, and all others — through the typed relationships of the Enterprise Ontology. Capabilities are among the most connected Noun Types in the Enterprise Model: they relate to Applications, Value Streams, Organizational Units, Data and Information Types, IT Portfolios, Processes, Vendors, and Regulatory Obligations. Capability-anchored cross-inventory queries are the primary path through which AI agents traverse from strategic intent to operational execution in the Enterprise Model.

Suggested Baseline

The content of this document — including all attribute categories, attribute definitions, maturity designations, governance guidance, and structural recommendations — represents the IF4IT’s current best thinking for building and governing a Capabilities Inventory. Everything presented here is a suggested baseline, not a mandate. No attribute is required. No category is mandatory. No structural pattern is enforced. Enterprises are explicitly encouraged to adapt, extend, and reshape everything in this document to match their specific context, vocabulary, regulatory environment, industry, and organizational maturity. The IF4IT does not guarantee that the attributes and guidance presented here are complete, exhaustive, or applicable to every enterprise in every context. Practitioners are the experts in their own organizations — use this document as a starting point, not a ceiling.