Services Inventory and Attributes

Section A — Sourcing and Harvesting

Before building the Services Inventory from scratch, assess whether all or part of it can be harvested from systems already operating in the enterprise. Many Service records exist — at least partially — in other platforms before a formal Services Inventory is established. Common sources include: the Service Catalog or service request platform (ServiceNow, BMC, Jira Service Management, Cherwell, etc.), where active requestable Services may already be defined with names, owners, descriptions, and request paths; the ITSM platform’s CMDB, where some Services may be modeled as Business Services or Service Configuration Items; the API Gateway or API Catalog (Apigee, Kong, AWS API Gateway, Azure API Management), where technology-delivered Services may be registered as published APIs; departmental intranet pages, portals, and SharePoint sites, where services are commonly documented informally and inconsistently; vendor management systems, where consumed Services may be tracked through Vendor or Contract records; and the Service Management Office (SMO) or Service Owner registry, where Service ownership assignments may be tracked in spreadsheets or governance documents. Harvesting from existing systems reduces the initial data entry burden, accelerates time to Crawl completeness, and surfaces records that manual discovery would miss — but harvested records will require deduplication, ownership reconciliation, and validation against the eight-point Service Definition before they qualify as governed Services.

AI agents can also serve as an effective harvesting tool — particularly for Services whose definitional information already exists in unstructured form across the enterprise. An AI agent can be prompted to scan intranet pages, departmental Confluence spaces, Service Catalog tooling exports, ITSM CI exports, and Vendor contracts to extract candidate Service definitions, propose Service Owners based on documented authorship and stewardship signals, and produce a draft set of Service records that practitioners then validate and complete. 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 the Service, 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 Service 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 Service records: a record owner is accountable for the attributes of one specific Service; the inventory owner is accountable for the schema, the governance process, and the overall health of the Services Inventory as a governance artifact.

For inventories with a natural organizational home — where a specific function already governs or consumes the Services — ownership should be assigned to that function. For the Services Inventory, the natural organizational home is the Service Management Office (SMO), the function leading Service Management as a discipline, or — in enterprises without a dedicated SMO — the function accountable for the Service Catalog and IT Service Management. For inventories 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. 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 Services Inventory is a living governance artifact. It must be actively maintained through a formal lifecycle — not treated as a one-time deliverable. Every Service record moves through defined lifecycle states aligned to the IF4IT Service Management Best Practices document: Proposed, Planned, Designed, Piloted, Active, Deprecated, Retired, Rejected, and Under Review. Lifecycle state is governed by the Service 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 warrants quarterly reconciliation minimum; Walk maturity warrants monthly reconciliation, or event-driven reconciliation on significant organizational, technology, or Service Catalog changes; Run maturity warrants continuous or near-continuous reconciliation, 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 Services 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: First, identify all known Services and create a stub record for each — Semantic ID, Service Name, and Description only. This produces a complete, if thin, inventory. Second, populate all remaining Crawl attributes across all records before any Walk attributes are added to any record. The Crawl attribute set for the Services Inventory aligns to the eight-point Service Definition from the IF4IT Single Service Definition Pattern — Service Owner, Service Definition Statement, Service Indicators / Objectives / Agreements, Service Inputs, Service Outputs, Service Manager, Service Providers / Service Actors, and Realizing Applications / Realizing Technologies. Third, validate Crawl completeness — 100% of known Services with 100% of Crawl attributes populated — before advancing. Fourth, populate Walk attributes systematically, one category at a time if necessary. Fifth, 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 Services Inventory contains governance-sensitive data. Access should be governed explicitly: read access broadly available to consuming stakeholders — Service Owners, Service Managers, EA, APM, TPM, the SMO, and IT Governance; write access restricted to the inventory steward, designated Service Owners (for their own records), 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 Services 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 a Service 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 Service involved in a significant decision — a Service that was the subject of a regulatory finding, a Service that experienced a major Incident, a Service that was the basis for a strategic Capability investment. For all others, define a retention period consistent with applicable regulatory requirements and organizational policy.