Capabilities Inventory and Attributes

Section A — Sourcing and Harvesting

Before building the Capabilities Inventory from scratch, assess whether capability definitions already exist in any form in the enterprise. Common sources include Enterprise Architecture tools and repositories — Archimate-based platforms, LeanIX, Bizzdesign, Sparx EA, and similar EA tools often contain partial or full capability maps; strategic planning documents and business architecture deliverables; and industry-standard capability frameworks that can be adapted as a starting point — BIZBOK (Business Architecture Guild) for general business capabilities, eTOM for telecommunications, BIAN for banking, HL7 FHIR for healthcare, and similar domain-specific frameworks. Harvesting from any of these sources reduces the initial definition effort and surfaces capability thinking that already exists in the organization but may not be formally governed.

AI agents are a particularly effective tool for bootstrapping a Capabilities Inventory, especially at Crawl maturity. An AI agent can be prompted to generate an initial set of Level 1, Level 2, and Level 3 Capability records for a given industry or industry segment, drawing from publicly available capability frameworks and general knowledge of enterprise functions. The IF4IT framework is intentionally AI-native — AI agents are first-class participants in inventory creation, population, and governance, not an afterthought. AI-generated records must be treated as a starting point requiring human validation, not as authoritative records. The generation method should be documented in the Provenance and Audit Attributes category of each AI-generated record so its origin is transparent and auditable.

Where no existing capability definitions exist and harvesting is not possible, the Capabilities Inventory must be built through structured discovery workshops with business and IT leaders. A facilitated session of two to four hours per business domain, with five to eight participants who understand both the business and IT dimensions of that domain, typically produces a workable Level 1 and Level 2 capability map. Start broad and iterate — a complete Level 1 capability map with sparse Level 2 entries is more useful than a deep but incomplete subtree.

Section B — Ownership and Accountability

Every inventory must have a named owner accountable for the accuracy, completeness, and governance of the inventory as a whole. Inventory ownership is distinct from the ownership of individual Capability records: a record owner is accountable for the attributes of one specific Capability; the inventory owner is accountable for the schema, the governance process, and the overall health of the Capabilities Inventory as a governance artifact. For the Capabilities Inventory, Enterprise Architecture is the natural organizational owner. In organizations without a formal Enterprise Architecture function, Business Architecture, Strategy, or a Center of Excellence that owns business design work is an appropriate alternative. Ownership by committee without a named accountable individual is not recommended — it produces diffused accountability and inconsistent governance.

Section C — Lifecycle and Review Cadence

The Capabilities Inventory is a living governance artifact. It must be actively maintained through a formal lifecycle — not treated as a one-time deliverable. Every Capability record moves through defined lifecycle states: Proposed, Active, Under Review, Deprecated, Retired, and Archived as appropriate. Lifecycle state is governed by the inventory owner and documented in the Lifecycle and Status Attributes category of each record. Reconciliation cadence should be established and enforced: Crawl maturity, quarterly reconciliation minimum; Walk maturity, monthly reconciliation, or event-driven on significant organizational or technology changes; Run maturity, continuous or near-continuous, automated where possible, with human review for exceptions. Reconciliation that happens informally and undocumented is reconciliation that did not happen for governance purposes.

Section D — Data Quality and Starting Approach

Do not attempt to populate all attributes for all Capabilities simultaneously. The most common failure mode for inventory initiatives is scope overreach — producing a large volume of incomplete records and losing organizational confidence in the data before any governance value is delivered. A second common failure mode is getting stuck on definitions — teams spending months debating whether something is a Capability or a sub-Capability, what to call it, and where it belongs, with no inventory produced. The IF4IT crawl-first methodology addresses both failures. Recommended approach: (1) Identify all known Capabilities and create a stub record for each — Semantic ID, Display Name, and Description only. This produces a complete, if thin, inventory. (2) Populate all remaining Crawl attributes across all records before any Walk attributes are added to any record. (3) Validate Crawl completeness — 100% of known Capabilities with 100% of Crawl attributes populated — before advancing. (4) Populate Walk attributes systematically, one category at a time if necessary. (5) Introduce Run attributes only when tooling and pipeline maturity justify automated derivation and calculation. The first version of the inventory will be wrong in places; the value comes from having it at all and then improving it iteratively. Treating the inventory as the goal misses the point — the decisions enabled by the inventory are the goal.

Section E — Access Control

The Capabilities Inventory contains governance-sensitive data. Access should be governed explicitly: read access broadly available to consuming stakeholders; write access restricted to the inventory steward, designated data owners, and authorized automated feeds; schema change access reserved for the inventory owner and governing body. At Crawl maturity, a shared spreadsheet with restricted edit access is a fully adequate access control model.

Section F — Change Management

The attribute schema of the Capabilities Inventory is itself a governed artifact. Schema changes — adding, removing, or renaming attributes — follow a five-step process: Propose → Review → Approve → Implement → Communicate. Schema changes should not be made during an active reconciliation cycle. Changes must be recorded in the inventory document’s change log. The same change-management discipline applies to the Capability Hierarchy itself: adding, renaming, repositioning, or retiring Capabilities is a governed action, not an ad hoc one. A capability map produced once and never maintained becomes worse than no map at all, because it actively misleads readers — disciplined change management is what keeps the inventory trustworthy.

Section G — Archival and Retention

When a Capability is retired, its record is not deleted — deletion destroys audit history. Update the Lifecycle Status to Retired, retain the record for one full reconciliation cycle in the active inventory, then archive it. Archived records remain queryable but are excluded from active governance reporting. Retain indefinitely any record for a Capability involved in a significant decision — acquisition, major investment, compliance finding. For all others, define a retention period consistent with applicable regulatory requirements and organizational policy.