Applications Inventory and Attributes

Section A — Sourcing and Harvesting

Before building the Applications Inventory from scratch, assess whether all or part of it can be harvested from systems already operating in the enterprise. Many application records exist — at least partially — in other platforms before a formal inventory is established. Common sources include a configuration management database (CMDB), an ITSM or service management platform, ERP and procurement systems, and software asset management or service catalog tooling. Harvesting from existing systems reduces the initial data entry burden, accelerates time to Crawl completeness, and surfaces records that manual discovery would miss.

AI agents can also serve as an effective harvesting tool — particularly for applications whose defining information is already documented across enterprise systems and vendor materials. An AI agent can be prompted to consolidate an initial set of application records from available sources, producing a draft inventory that practitioners validate and extend rather than building from scratch. This approach is especially effective at Crawl maturity, where the goal is breadth and completeness over depth. Practitioners should treat AI-generated records as a starting point requiring human validation — not as authoritative records — and should document the generation method in the Provenance and Audit Attributes category of each AI-generated record so its origin is transparent and auditable.

Where harvesting is not possible — because no source system tracks applications completely, because source data quality is insufficient, or because the attributes required go beyond what any source system captures — the inventory must be built and maintained manually. Manual inventory governance is entirely viable at Crawl and Walk maturity. It requires discipline, clear ownership, and a regular reconciliation cadence — but it is not a failure mode. The most important thing is that the inventory exists, is accurate, and is actively maintained. The tooling and automation can come later.

Section B — Ownership and Accountability

Every inventory must have a named owner — an individual or function that is accountable for the accuracy, completeness, and governance of the inventory as a whole. Inventory ownership is distinct from the ownership of individual application records: a record owner is accountable for the attributes of one specific application; the inventory owner is accountable for the schema, the governance process, and the overall health of the Applications Inventory as a governance artifact.

For inventories with a natural organizational home — where a specific function already governs or consumes the applications — ownership should be assigned to that function. For the Applications Inventory with no clear organizational owner, the IF4IT recommends assigning ownership to a cross-functional function such as Enterprise Architecture, which already governs the Enterprise Model of which this inventory is a component, or Software Engineering, where the applications are primarily technology-facing. 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 Applications Inventory is a living governance artifact. It must be actively maintained through a formal lifecycle — not treated as a one-time deliverable. Every application 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 — how often the inventory is reviewed and reconciled against source systems or organizational reality — 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. Establish a formal reconciliation event with documented outcomes, owned by the inventory steward.

Section D — Data Quality and Starting Approach

Do not attempt to populate all attributes for all applications 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.

Recommended approach:

1. Identify all known applications 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 applications 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.

Quality thresholds: Crawl attributes must be 100% complete before Walk begins. All records should be validated against at least one authoritative source at creation and at each reconciliation. Records that cannot be validated should be flagged with a data quality indicator in the Provenance and Audit Attributes category.

Section E — Access Control

The Applications 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 Applications 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.

Section G — Archival and Retention

When an application 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 an application 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.