Capabilities Inventory and Attributes - Descriptive Attributes for the Capabilities Inventory
Capabilities Inventory and Attributes
Descriptive Attributes for the Capabilities Inventory
Descriptive attributes capture the core identity of each Capability Noun Instance — what it is called, what it means, where it sits in the hierarchy, and the alternate names by which it is known across the enterprise.
| Attribute Name | Maturity | Description and Notes |
|---|---|---|
| UID | Crawl | Description — A machine-readable system identifier generated by any source system that created or imported this Capability record. Optional — populated only when the Capability is sourced from an external system that assigns its own identifiers. Benefit(s) — Enables automated reconciliation between the Capabilities Inventory and source systems without relying solely on name matching. Source — Manual Examples — CAP-00147, BCE-2041, LX-CAP-009832 Notes — Complements the Semantic ID. Leave empty when no source system generates an ID. Never reused after retirement. |
| Semantic ID | Crawl | Description — A unique, human-readable, self-documenting identifier assigned to every Capability following the enterprise naming convention. Permanent and never reused once assigned. The connective tissue of the Enterprise Model — enables cross-inventory traversal without ambiguity. Benefit(s) — Eliminates ambiguity when the same Capability is referenced across APM, TPM, Enterprise Architecture deliverables, and the Enterprise Model. Enables AI-assisted cross-inventory traversal without ETL transformation. Source — Manual Examples — /Enterprise/Core Business Capabilities/Human Capital Management/Resource Training and Education (path-based form); CAP-FIN-AP-INV-PROC (tokenized form) Notes — For hierarchical Noun Types like Capabilities, the path-based form is recommended — the full path from root to node provides a natural, unambiguous, self-describing identifier that encodes the Capability’s position in the hierarchy. The tokenized form (CAP-{L1Domain}-{L2Domain}-{ShortName}) remains an acceptable alternative for enterprises that prefer compact identifiers. Unlike the Hierarchy Identifier, which is positional and changes with reorganization, the Semantic ID identifies the Capability for the life of the inventory regardless of subsequent structural changes. |
| Hierarchy Identifier | Crawl | Description — A dotted-notation positional identifier reflecting the Capability’s current position in the hierarchy. Useful for compact display, natural-order sorting, and conversational reference. Benefit(s) — Provides a short, sortable handle for every Capability that fits in tight display contexts where the full Semantic ID is too long. Source — Manual Examples — 1.0, 1.3, 1.3.2 Notes — CAVEAT — this value is not a unique identifier and must not be used as one. It is positional and changes whenever the hierarchy is reorganized — when Capabilities are reordered, inserted, moved, or removed. A given Hierarchy Identifier does not durably refer to the same Capability over time. For durable cross-references, use the Semantic ID. The Hierarchy Identifier is a display convenience; the Semantic ID is the identity. |
| Display Name | Crawl | Description — The plain-English name of the Capability as it appears in capability maps, reports, dashboards, and practitioner communications. Benefit(s) — Produces a capability map immediately readable by business stakeholders. Separates permanent identity (Semantic ID) from current preferred label. Source — Manual Examples — Invoice Processing, Sales Opportunity Management, Vulnerability Management |
| Leaf Capability Name | Walk | Description — The terminal segment of the Capability’s hierarchical path — the name of the Capability considered in isolation from its ancestors. Derived from the final path segment of the Semantic ID when the path-based form is used. Benefit(s) — Provides a queryable column for the terminal name that distinguishes label drift from identity change. Source — Derived Examples — Resource Training and Education, Invoice Processing, Vulnerability Management Notes — For most Capabilities, this value is identical to the Display Name. The two attributes serve different roles. Display Name is the label used in human-facing contexts and may be updated for clarity without changing the Capability’s identity. Leaf Capability Name reflects the path-encoded position and changes only when the Capability’s Semantic ID changes. When the two values differ, it signals that the Capability’s display label has been updated since its position in the hierarchy was last reset. |
| Description | Crawl | Description — A comprehensive description of the Capability — what the enterprise does or must be able to do in this capability area, the outcomes it produces, and how it differs from adjacent Capabilities. Benefit(s) — The quality of the Description is the most important predictor of whether the Capabilities Inventory remains usable over time. Source — Manual Notes — Write in terms of outcomes and abilities, not activities or tools. Good: “The ability to receive, validate, and process supplier invoices.” Poor: “AP team uses SAP to process vendor bills.” |
| Parent Capability Path [Hierarchical] | Crawl | Description — The full path from the root of the Capability Hierarchy to the immediate parent of this Capability, expressed as a forward-slash-delimited string ending with a trailing slash. A root-level Capability has a Parent Capability Path of “Not Applicable”. Benefit(s) — Provides complete hierarchical positioning in a single attribute. Enables path-based queries. Source — Manual Examples — /Enterprise/Core Business Capabilities/Human Capital Management/ (Level 4 parent); /Enterprise/ (Level 2 parent); Not Applicable (root) Notes — Use Display Names, not Semantic IDs, in the path. Update on all descendants when a parent’s Display Name changes. The path always ends in a trailing slash to distinguish it from terminal node references. |
| Aliases / Alternate Names [Multi-Value] | Walk | Description — Other names by which this Capability is known across the enterprise — synonyms, predecessor names from prior taxonomies, team-specific vocabulary, or external framework names that map to this Capability. Benefit(s) — Eliminates cross-document reconciliation failures when the same Capability is referenced by different names in different artifacts. Supports AI-assisted name resolution during inventory harvesting. Source — Manual Examples — AP Processing; Vendor Invoice Management; Supplier Bill Handling Notes — Separate multiple aliases with semicolons. Use Not Applicable when no aliases exist. |
Copyright for the International Foundation for Information Technology (IF4IT): 2008 - Present
Legal Disclaimers