Services Inventory and Attributes

What Is a Service in This Inventory

A Service in this inventory is a defined, governed offering — business or technical — that the enterprise provides to or receives from a defined set of consumers, with associated obligations, ownership, lifecycle, and operational behavior. The defining characteristic is governance: the Service has been deliberately defined, has an accountable owner, has performance expectations, and has been committed to governance as a managed value-delivery asset. Per the IF4IT Single Service Definition Pattern, a governed Service in this inventory has eight defining elements present: a clearly identified and accountable Service Owner; a clearly defined purpose and description; clearly defined performance expectations consisting of Service Indicators, Service Objectives, and Service Agreements; clearly defined inputs; clearly defined outputs; a clearly defined Service Manager; clearly defined Service Providers / Service Actors; and clearly defined supporting tools and technologies.

A Service Noun Instance is the governed record of that Service — not a specific Service Request, Service Record, Service Action, or Service Outcome. The same Service is represented by one record regardless of how many Service Requests have been submitted against it. The Service Records are governed in the Service Records system (typically an ITSM platform); the Service Catalog presentation is governed in the Service Catalog tooling; the Service Performance metrics are governed in monitoring and reporting platforms. The Services Inventory governs the Service definition itself and connects to all of these other systems through typed relationship attributes.

The Service Definition and Execution Pattern

The Service Definition and Execution Pattern from the IF4IT Service Management Best Practices document is the underlying conceptual model that gives every governed Service a common structure regardless of whether it is human-delivered, technology-delivered, or hybrid. The pattern has six structural elements: Service Expectations (the predefined requirements set by the Service Owner, composed of Service Indicators, Service Objectives, and Service Agreements); Service Requester (the person, organization, or system that requests or consumes the Service — also known as the Service Customer); Service Request (the specification, instruction, trigger, input, or set of criteria submitted to initiate the Service); Service Provider — also known as Service Actor (the person, team, system, application, automation, or technology that performs the work); Service Action (the work performed in response to the Service Request); and Service Outcome (the result produced, which may include a Service Response, deliverable, completed transaction, changed state, notification, record update, or other measurable result).

This pattern is encoded in the attribute structure of the Services Inventory. Service Expectations are represented through Service Indicator Set, Service Objectives, and Service Agreement Reference attributes in the Operational category. Service Requesters are represented through the Service Requester Community attribute in the Ownership and Stakeholder category. Service Providers and Service Actors are represented as Crawl-level Ownership and Stakeholder attributes. Service Inputs and Service Outputs are Crawl-level Descriptive attributes. The Service Action and Service Outcome are governed in the operational Service Records system, not in this inventory — but the Services Inventory connects to that system through the Service Records Source attribute.

Services Are Not Applications, Tools, or Processes

The IF4IT Service Management Best Practices document is explicit that the word “service” is often used inconsistently in enterprises — to describe Help Desk tickets, software applications, business processes, technology platforms, and team activities. When everything is called a service, the term loses its usefulness as a governance, management, and operating construct. The Services Inventory governs only those offerings that meet the definitional criteria of a governed Service. Other constructs that are commonly confused with Services are governed in their own inventories.

An Application is not automatically a Service. An Application is a software solution that runs in an operating environment to support one or more business or technical capabilities, and may enable many Services through its features, APIs, workflows, and integrations. An enterprise application like a CRM platform may enable customer onboarding services, account management services, reporting services, and notification services — but the CRM application itself is not a Service. The CRM application is governed in the Applications Inventory; the Services it enables are governed in the Services Inventory. The boundary matters because conflating them prevents the enterprise from rationalizing Applications independently of the Services those Applications enable, and prevents the enterprise from governing Service performance independently of the Applications that happen to implement those Services.

A Process is not a Service. A Process is a sequenced activity that orchestrates work to produce a business outcome — it may exercise one or more Services as part of its sequencing, but the Process itself is governed by the Processes Inventory, not the Services Inventory. Similarly, a Capability is not a Service: the Capability is the standing ability the enterprise possesses; the Service is the deliberate, contracted offering through which that ability becomes operationally available to a Service Requester Community. The Service realizes the Capability; the Capability does not realize the Service.

Service Catalog, Service Portfolio, and Service Pipeline

The Service Catalog, Service Portfolio, and Service Pipeline are three related but distinct constructs that practitioners of Service Management must understand and that the Services Inventory must clearly position itself against. The IF4IT Service Management Best Practices document treats this distinction in detail. The summary: the Services Inventory is the broadest of the three — it governs every Service across every lifecycle state. The Service Portfolio is the management view that organizes the inventory by lifecycle, ownership, group, and strategic context. The Service Pipeline is the subset of the portfolio in Proposed, Planned, Designed, or Piloted states. The Service Catalog is the requester-facing view of Services in the Active state that have been published for engagement.

The Services Inventory and the Service Catalog are peer governance artifacts within Service Governance: both register Service Definitions, but they serve different audiences and lifecycle scopes. The inventory governs Services across all lifecycle states for governance, planning, and analysis purposes; the catalog publishes the active, requestable subset for requester discovery and engagement. The two are connected through the Catalog Visibility attribute and through the Catalog Manager and Service Engagement Owner ownership roles. A Service may appear in the inventory long before it appears in the catalog (during the Pipeline stage), may appear in both during the Active stage, and may continue to appear in the inventory after it has been removed from the catalog (during Deprecation or Retirement). Refer to the IF4IT Service Catalog Best Practices document for detailed catalog governance and the IF4IT Service Management Best Practices document for the Service Portfolio and Service Pipeline disciplines.

Service Ownership and Accountability

Service ownership is the foundation of governable Service Management. Every governed Service in this inventory must have a named, accountable Service Owner — the individual or role accountable for the Service’s definition, value, boundaries, performance expectations, lifecycle state, and continuous improvement. Service ownership is distinct from Service operation: the Service Owner is accountable for what the Service is and why it exists; Service Providers and Service Actors are responsible for performing the work of the Service; the Service Manager (when distinct) coordinates day-to-day operational delivery. These roles are related but not the same.

Beyond the Service Owner and Service Manager, the Services Inventory governs a richer set of ownership roles. The Service Provider Organization is the internal or external organization providing the Service. The Service Requester Community is the population of consumers the Service is for. The SME Teams (Subject Matter Expert teams) are the specialist fulfillment teams that handle Service Requests escalated from the Service Desk. The Catalog Manager is the role accountable for the Service Catalog entry. The Service Engagement Owner is the role accountable for engagement channel content. The Portfolio Owner is the role accountable for the Service Portfolio to which this Service belongs. The Service Group Owner is the role accountable for the Service Group. Some Services will have one named individual filling all of these roles; large enterprises typically have different individuals or functions accountable for each. Each ownership role is governed as a separate inventory attribute so that role-specific governance queries remain clean and explicit.

The Service Lifecycle

Every governed Service has a lifecycle. The IF4IT Service Management Best Practices document defines nine canonical lifecycle states that align with the Lifecycle Status attribute in this inventory: Proposed (the Service has been suggested but not yet committed to design), Planned (the Service has been committed to and is awaiting design), Designed (the Service Definition is complete but not yet implemented), Piloted (the Service is in limited operational use for validation), Active (the Service is in normal operational use and available to its Service Requester Community), Deprecated (the Service remains operational but is being phased out, typically with a documented successor or alternative), Retired (the Service is no longer operational), Rejected (the Service was proposed but will not be implemented), and Under Review (the Service is being reassessed and may move to another state). Lifecycle state is governed by the Service Owner and updated through a documented governance process — not by individual practitioners changing it ad hoc.

Lifecycle discipline matters for two reasons. First, Service Requesters need to know whether a Service is available, being phased out, or no longer supported — a Service in Deprecated state warrants different consumer guidance than one in Active state. Second, Service Portfolio and Service Pipeline reporting depend on accurate lifecycle state across the entire inventory — a Service stuck in Proposed state for two years distorts pipeline reporting; a Service marked Active but actually unmaintained distorts portfolio health reporting. Lifecycle accuracy is a Crawl-maturity attribute precisely because it is foundational to all higher-order Service Portfolio analysis.

Service Governance and the Enterprise Model

The Services Inventory is one component of the broader IF4IT Enterprise Model. The Enterprise Model is the semantic graph of the enterprise — the connected network of Noun Types, Noun Instances, and typed relationships through which an enterprise can be reasoned over by humans and by AI agents. The Services Inventory contributes the Service dimension of that graph: every governed Service is a node in the Enterprise Model, with typed edges to the Capabilities it realizes, the Applications that enable it, the Technologies it depends on, the Vendors that provide it, the Contracts that govern it, the Value Streams it participates in, and the Risks, Incidents, and Problems associated with it.

The Services Inventory is part of Service Governance — the discipline of overseeing the enterprise’s Services as a portfolio of governed value-delivery assets. Service Governance encompasses both the Services Inventory (the system of record for Service definitions) and the Service Catalog (the requester-facing view of active Services), along with the operational discipline of Service Management itself. The three together form the governance instrument by which the enterprise oversees its Services as a managed portfolio rather than as a fragmented collection of ad hoc offerings. Practitioners who govern the Services Inventory should read the IF4IT Service Management Best Practices document, the IF4IT Service Catalog Best Practices document, and the IF4IT Enterprise Inventory Management Best Practices document together with this one — the four documents are mutually reinforcing components of a single governance program.