Services Inventory and Attributes on The International Foundation for Information Technology (IF4IT)

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

About This Inventory

The Services Inventory governs every Service the enterprise has chosen to govern — every named, owned, defined offering that meets the criteria of a governed Service. Each Noun Instance is a single Service with its own Semantic ID, its own Service Owner, its own Service Definition (purpose, description, inputs, outputs, performance expectations, and supporting tools), and its own complete set of governance attributes. A Service in this inventory is distinct from an Application (which may enable many Services), a Capability (which is the standing ability a Service realizes), a Service Request or Service Record (which is a single transactional instance of a Service being invoked), and a Process (which orchestrates work, sometimes by exercising one or more Services). The inventory is the enterprise’s single source of truth for the answer to the question: what Services do we govern, who owns them, what do they deliver, and how do they connect to the rest of the Enterprise Model?

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

The following terms are used throughout this document with specific meanings. Terms defined in the IF4IT Enterprise Inventory Management Best Practices document or in discipline-specific Best Practices documents (APM, TPM, etc.) are not duplicated here — refer to those documents for broader inventory governance and discipline-specific vocabulary.

Term	Definition
Service	A defined, governed offering — business or technology — that the enterprise provides to or receives from a defined set of consumers, with associated obligations, ownership, lifecycle, and operational behavior. A governed Service has clearly identified ownership, defined purpose and description, defined performance expectations, defined inputs and outputs, defined Service Manager, defined Service Providers / Service Actors, and defined supporting tools and technologies. Distinct from an Application (which may enable many Services), a Capability (which is the standing ability a Service realizes), and a Service Request (which is a single transactional instance of a Service being invoked).
Service Definition	The formal specification of what a Service is, who it serves, what it consumes, what it produces, and how it performs. Per the IF4IT Single Service Definition Pattern, a complete Service Definition includes eight elements: a clearly identified and accountable Service Owner, a clearly defined purpose and description, clearly defined performance expectations (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.
Service Owner	The single named individual or role accountable for a Service’s definition, value, boundaries, performance expectations, lifecycle state, and continuous improvement. Distinct from the Service Manager (who coordinates day-to-day operations), the Service Provider / Service Actor (who performs the work), and the Service Customer / Service Requester (who consumes the Service).
Service Manager	The role responsible for day-to-day operational coordination of a Service — managing queues, providers, schedules, escalations, handoffs, operating procedures, knowledge articles, fulfillment quality, and service reporting. In smaller organizations, the Service Owner and Service Manager may be the same person; in larger organizations they are typically separate roles.
Service Provider (a.k.a. Service Actor)	The person, team, system, application, automation, or technology that performs the work needed to fulfill a Service Request and produce a Service Outcome. Service Providers may be internal (Service Desk staff, application support teams, automated workflows) or external (vendor support teams, SaaS platforms).
Service Requester (a.k.a. Service Customer)	The person, organization, or system that requests, invokes, or consumes a Service. Service Requesters may be internal (employees, internal teams, internal applications) or external (customers, partners, external systems). The collective set of Service Requesters for a given Service is the Service’s Service Requester Community.
Service Request	A specification, instruction, trigger, input, or set of criteria submitted by a Service Requester to initiate a Service. Also informally known as a Service Ticket. A Service Request is a single transactional instance of a Service being invoked — not the Service definition itself.
Service Action	The work performed by one or more Service Providers in response to a Service Request. The Service Action is bounded by the Service Definition and produces a Service Outcome.
Service Outcome	The result produced by a Service Provider according to the Service’s predefined Service Expectations. A Service Outcome may include a Service Response, a deliverable, a completed transaction, a changed state, a notification, a record update, or another measurable result.
Service Response	A specific form of Service Outcome — typically an immediate or near-immediate response delivered back to the Service Requester. Common for technology-delivered Services (API request/response patterns) and some human-delivered Services (Service Desk acknowledgement).
Service Expectations	A set of predefined requirements set by the Service Owner for how a Service will be structured, enabled, and performed in a manner that guarantees measurable, predictable, and acceptable results. Composed of three traits: Service Indicators, Service Objectives, and Service Agreements.
Service Indicator	An observable or measurable signal used to understand Service demand, performance, quality, behavior, risk, experience, or outcome. Service Indicators provide the measurement foundation for Service Objectives, Service Agreements, Service Reports, and continuous improvement.
Service Objective	A target, threshold, or desired range for one or more Service Indicators over a defined period or operating context. Service Objectives translate measurement into performance intent.
Service Agreement	A documented commitment, understanding, or agreement that defines responsibilities, expectations, targets, assumptions, escalation paths, and responses when expectations are met or missed. A Service Agreement may be a formal Service Level Agreement (SLA), an internal operating commitment, a support agreement, a customer-facing service commitment, or a documented understanding between the Service Owner and the Service Requester Community. Not every Service Agreement has formal legal or financial consequences.
Service Catalog	The requester-facing view of approved, active, requestable, invokable, or consumable Services. A curated subset of the broader Service Portfolio. The Service Catalog is a peer of the Services Inventory within Service Governance: the inventory governs the full set of Services across all lifecycle states; the catalog publishes the subset that is requester-facing and active. Refer to the IF4IT Service Catalog Best Practices document for detailed catalog governance guidance.
Service Portfolio	The broader governed collection of Services managed by the organization or organizational unit across lifecycle states — Proposed, Planned, Designed, Piloted, Active, Deprecated, Retired, Rejected, and Under Review. The Service Portfolio is the strategic, lifecycle-aware view of all Services; the Service Catalog is the requester-facing view of the active subset.
Service Pipeline	The portion of the Service Portfolio containing proposed, planned, designed, or in-development Services that are not yet fully operational or approved for normal consumption. The Service Pipeline is the controlled path from Service idea to operational Service.
Service Group	A logical grouping of related Services — typically by fulfillment responsibility, service area, requester community, operational capability, or business context. Service Groups sit between individual Services and Service Portfolios in scale, and may have a Service Group Owner accountable for the group’s coherent governance.
Service Engagement Channel	An approved path through which Service Requesters interact with a Service to request, invoke, or consume it. Common Service Engagement Channels include the Service Catalog, departmental portals, workflow forms, API catalogs, automation platforms, chat interfaces, the Service Desk, and intranet pages. A single Service may be exposed through multiple Service Engagement Channels.
Service Record	A governed record of a single Service Request — the request itself, the action taken, the status, the evidence captured, and the outcome produced. Service Records are transactional, not definitional: the Services Inventory governs Service definitions; the Service Record system governs the operational instances of Services being invoked. Service Records are also informally known as Service Tickets.
Service Desk (a.k.a. Help Desk)	The operational function that receives Service Requests, performs initial triage and routing, fulfills simple Service Requests directly, escalates complex Service Requests to Subject Matter Expert teams, and serves as the front door for Service Management. The Service Desk is part of the Service Provider Workforce alongside Service Providers / Service Actors.
Subject Matter Expert (SME) Team	A specialist fulfillment team that handles complex Service Requests escalated from the Service Desk. SME Teams provide deeper technical or domain expertise than the Service Desk maintains directly. Distinct from Service Providers / Service Actors who handle routine fulfillment.
Service Governance	The discipline of overseeing the enterprise’s Services as a portfolio of governed assets — ensuring every Service has defined ownership, accountable lifecycle management, current Service Definitions, measurable performance, and clear connection to the broader Enterprise Model. The Services Inventory and the Service Catalog are peer governance instruments within Service Governance.
Service Lifecycle	The defined sequence of states a Service may pass through during its existence. The IF4IT Service Management Best Practices document defines nine canonical states: Proposed, Planned, Designed, Piloted, Active, Deprecated, Retired, Rejected, and Under Review. Lifecycle state is governed by the Service Owner and recorded in the Lifecycle Status attribute of every Service record.
Service Roadmap	The forward-looking plan for a Service — its planned evolution, improvements, capability additions, deprecations, and strategic direction. Every governed Service should have a Service Roadmap maintained by the Service Owner. Refer to the IF4IT Service Management Best Practices document for Service Roadmap governance guidance.
Service Inputs	What flows into a Service for it to function — data inputs, trigger inputs, resource inputs, material inputs, knowledge or instruction inputs, or any other inputs the Service consumes to produce its Service Outcomes. Captured as descriptive text in the Services Inventory and elaborated in formal interface specifications where they exist.
Service Outputs	What flows out of a Service as a result of its operation — data outputs, state changes, decisions, notifications, deliverables, transactions, or any other outputs the Service produces. Captured as descriptive text in the Services Inventory and elaborated in formal interface specifications where they exist. Distinct from Service Outcomes (which describe the result for the Service Requester); Service Outputs describe what the Service emits or changes regardless of who receives it.
Service Tier	The strategic importance classification of a Service to the enterprise. Common tier schemes: Tier 1 (Critical — enterprise cannot operate without this Service), Tier 2 (Important — significant impact if degraded), Tier 3 (Standard — manageable impact), Tier 4 (Commodity — easily replaceable). Service Tier drives governance investment proportional to Service importance.
Service Delivery Mode	How a Service is delivered to its Service Requester Community. Common values: Human-Delivered (work performed primarily by people), Technology-Delivered (work performed primarily by automated systems), or Hybrid (a combination of human and technology delivery).
Service Consumption Mode	How a Service is engaged by its Service Requester Community. Common values: Requestable (the Service Requester submits a Service Request through a Service Engagement Channel), Invokable (the Service is triggered programmatically, typically through an API), Consumable (the Service is continuously available for direct use), or Subscribed (the Service Requester has standing access to the Service through a subscription).
Service Direction	Whether a Service is offered by the enterprise, consumed by the enterprise, or both. Common values: Internal-Provided (the enterprise offers the Service to internal Service Requesters), External-Provided (the enterprise offers the Service to external Service Requesters), Internal-Consumed (the enterprise consumes the Service from internal Service Providers), External-Consumed (the enterprise consumes the Service from external Service Providers — typically Vendors), or Both.
Service Engagement Owner	The role accountable for the accuracy and currency of a Service’s representation across its Service Engagement Channels — keeping descriptions, request links, required inputs, response expectations, and support paths consistent across the Service Catalog, portals, intranet pages, API catalog entries, chatbot answers, and other engagement surfaces.
Catalog Manager	The role accountable for the accuracy, currency, and structure of Service Catalog entries — a peer governance role to the Service Engagement Owner with specific accountability for the Service Catalog as a managed governance artifact. Refer to the IF4IT Service Catalog Best Practices document for Catalog Manager guidance.
Portfolio Owner	The role accountable for the overall health, strategic direction, investment, value, lifecycle balance, and performance of a Service Portfolio. Portfolio Owners govern at the portfolio level; individual Service Owners govern at the Service level. The two ownership levels are complementary, not redundant.
Service Group Owner	The role accountable for the coherent governance of a Service Group — typically a logical grouping of related Services. Service Group Owners coordinate cross-Service governance for the group, including consistency of Service Definitions, alignment of Service Expectations, and shared engagement standards.
Service Records Source	The authoritative system of record for the Service Records of a given Service — the platform (typically an ITSM tool, ticketing system, workflow platform, or API gateway log) where individual Service Request transactions are captured, tracked, and reported.
Service Completion Definition	The specific, governed definition of what completion means for a Service Outcome and Service Response. Completion definitions help Service Providers, Service Actors, Service Requesters, and Service Owners share a common understanding of when a Service Request is genuinely fulfilled rather than informally closed.
Fulfillment Responsibility Model	The structure that defines who performs Service Action work for a Service. Common values: Single-Team (one team fulfills all Service Requests), Multi-Team (multiple internal teams share fulfillment), Cross-Org (fulfillment crosses organizational boundaries), Vendor (a Vendor performs primary fulfillment), or Automated (a system or workflow performs primary fulfillment).

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

The Services Inventory governs every Service the enterprise has chosen to govern as a managed value-delivery asset — every named, owned, defined offering that meets the criteria of a governed Service per the IF4IT Single Service Definition Pattern. A governed Service has 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 and outputs; a clearly defined Service Manager; clearly defined Service Providers / Service Actors; and clearly defined supporting tools and technologies. A Noun Instance in this inventory is a single Service — not a Service Request, a Service Record, a Service Ticket, an Application, a Capability, or a Process. The inventory governs Service definitions; the operational systems of record govern Service transactions and Service performance.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

The Services Inventory is essential to several IT Management disciplines. The four mandatory disciplines for every IF4IT inventory document — Enterprise Architecture, Application Portfolio Management (APM), Technology Portfolio Management (TPM), and Enterprise Inventory Management (EIM) — each depend on the Services Inventory in specific ways. Additional disciplines with direct dependencies on the Services Inventory — Service Management, Service Catalog Management, Business Architecture, and IT Governance — are addressed at the end of this section.

Enterprise Architecture depends on the Services Inventory because Services are first-class architectural elements in the Enterprise Model — the deliberate, contracted offerings through which Capabilities are realized for defined Service Requester Communities. EA cannot model the enterprise’s value-delivery surface without governing Services as inventoried assets. Without a Services Inventory, EA models Capabilities and Applications but cannot connect them through the Service layer that turns capability into delivered value — leaving Enterprise Model analysis, target-state design, and architectural roadmap work incomplete. The Services Inventory enables EA to answer questions that are otherwise unanswerable: which Services realize which Capabilities, which Applications enable which Services, which Services depend on which Technologies, and where in the Service portfolio the enterprise is over- or under-invested relative to strategic Capability priorities.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

The Services Inventory does not exist in isolation. It connects to other inventories in the IF4IT Enterprise Inventory Management taxonomy through typed, governed relationships that together form the Service-centered portion of the Enterprise Model. The relationships described here are the most important ones; the complete relationship surface is enumerated in the Relationship Attributes category of this document and elaborated in the Relationships to Other Inventories subsection at the end.

The Services Inventory has a foundational relationship with the IF4IT Capabilities Inventory and Attributes. Services realize Capabilities — every governed Service exists to make one or more Capabilities operationally available to a Service Requester Community. The Capability is the standing ability; the Service is the contracted, delivered, governed offering through which that ability becomes accessible. A Capability without any Services realizing it is an unrealized strategic intent; a Service that does not realize a Capability is a misclassified activity. The Services Inventory connects to the Capabilities Inventory through the Capability Realization attribute, enabling enterprise-wide analysis of which Capabilities are well-supported by Services, which are under-served, and where the Service portfolio is misaligned with Capability strategy.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

The Services Inventory is one Noun Type inventory among the forty-five Noun Type inventories that constitute the IF4IT Enterprise Inventory Management taxonomy — the master catalog of all Noun Types the enterprise recognizes and tracks. The full taxonomy, the inventory governance principles that apply across every inventory in it, the Inventory of Inventories, and the framework for connecting inventories into the Enterprise Model are documented in the IF4IT Enterprise Inventory Management Best Practices document. Practitioners using this inventory should read that document as the broader governance context.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

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.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

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.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Descriptive attributes capture the identity, definition, and substantive identity of each Service — what it is, what it consumes, what it produces, and what value it delivers. These attributes are foundational; without them, the Service cannot be identified or distinguished as a governable asset.

Attribute Name

Maturity

Description and Notes

Semantic ID

Crawl

Description — A unique, permanent, human-readable identifier assigned to every Service following the enterprise naming convention. The identifier encodes the inventory type and the specific Service identity in its structure.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Classification attributes position each Service within the enterprise Service taxonomy — its type, delivery and consumption modes, direction, customer segment, category, tier, and catalog visibility. Classification enables portfolio-level analysis and Service Catalog organization.

Attribute Name

Maturity

Description and Notes

Service Type

Crawl

Description — The primary classification of what kind of Service this is. Drives governance pattern selection: different Service Types warrant different governance intensity, different Service Expectation patterns, and different ownership models.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Ownership and Stakeholder attributes establish the accountability structure for each Service — who owns it, who manages it operationally, who provides it, who consumes it, and the governance roles that surround it. Per the IF4IT Single Service Definition Pattern, three of these ownership roles (Service Owner, Service Manager, and Service Providers / Service Actors) are foundational to the Service Definition itself.

Attribute Name

Maturity

Description and Notes

Service Owner

Crawl

Description — The single named individual or role accountable for the Service’s definition, value, boundaries, performance expectations, lifecycle state, and continuous improvement. Aligns with the first element of the IF4IT Single Service Definition Pattern.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Lifecycle and Status attributes record where each Service is in its lifecycle, what its current availability is, and the dates that anchor lifecycle transitions. Lifecycle accuracy is foundational to all higher-order Service Portfolio analysis.

Attribute Name

Maturity

Description and Notes

Lifecycle Status

Crawl

Description — The current lifecycle state of the Service. Aligns with the nine canonical states defined in the IF4IT Service Management Best Practices document.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Governance attributes capture how each Service is governed — by which body, with what cadence, and with what change-approval authority. These attributes connect Service-level governance to the broader enterprise governance structure.

Attribute Name

Maturity

Description and Notes

Governance Council / Body

Walk

Description — The governance body that approves substantive changes to the Service — Service Definition changes, Service Expectations changes, ownership transfers, lifecycle state changes, and retirement decisions.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Strategic attributes position each Service in the enterprise’s strategic context — its importance, the Capabilities it realizes, the Value Streams it participates in, and its forward-looking roadmap. These attributes connect Service-level governance to strategy.

Attribute Name

Maturity

Description and Notes

Strategic Importance

Crawl

Description — The strategic importance classification of the Service in the enterprise’s strategic context. Distinct from Service Tier: Service Tier reflects operational criticality; Strategic Importance reflects strategic positioning.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Assessment and Health attributes record the current health and consumer-satisfaction state of each Service. These attributes provide governance visibility distinct from real-time operational monitoring — the assessment captures the considered view of Service health, not the moment-by-moment operational state.

Attribute Name

Maturity

Description and Notes

Service Health Rating

Walk

Description — A summary rating of the Service’s current health, typically derived from multiple operational signals (performance against objectives, customer satisfaction, incident frequency, governance review findings).

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Technical attributes capture the technical realization of each Service — the Applications, Technologies, and Integrations that enable it, the cloud hosting model, and the API surface. Per the IF4IT Single Service Definition Pattern, the realizing Applications and realizing Technologies (the supporting tools and technologies) are foundational to the Service Definition itself.

Attribute Name

Maturity

Description and Notes

Realizing Applications

[Multi-Value]

Crawl

Description — The Applications that enable this Service. References the Applications Inventory by Semantic ID. Aligns with the eighth element of the IF4IT Single Service Definition Pattern (supporting tools and technologies) and with the IF4IT Service Management Best Practices guidance that Applications enable Services.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Operational attributes capture how each Service operates day-to-day — its Service Expectations (Indicators, Objectives, Agreements), its hours and coverage, its engagement channels, its completion definitions, its fulfillment structure, and its escalation processes. Per the IF4IT Single Service Definition Pattern, Service Expectations are foundational to the Service Definition itself, which is why Service Indicators, Service Objectives, and Service Agreement Reference appear here at Crawl maturity.

Attribute Name

Maturity

Description and Notes

Service Indicator Set

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Security attributes capture each Service’s security posture — sensitivity classification, authentication and authorization, data classification handled, security review status, encryption posture, and identity provider. These attributes support security governance and compliance discipline.

Attribute Name

Maturity

Description and Notes

Service Sensitivity Classification

Crawl

Description — The sensitivity classification of the Service — what level of confidentiality, integrity, and availability protection the Service warrants.

Benefit(s) — Drives security control selection proportional to Service sensitivity. Enables compliance reporting by sensitivity tier. Supports incident triage and response prioritization.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Data and Information attributes capture each Service’s relationship to enterprise data — the data types handled, the data stores accessed, the retention period, and any residency constraints. These attributes connect the Service to the Data and Information governance discipline.

Attribute Name

Maturity

Description and Notes

Data Types Handled

[Multi-Value]

Walk

Description — The data and information types the Service consumes or produces. References the Data and Information Inventory by Semantic ID where the data types are governed there.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Geographic and Jurisdictional attributes capture where each Service is offered, where it is consumed, and any jurisdictional restrictions. These attributes support compliance with regional and jurisdictional regulations and enable geographic portfolio analysis.

Attribute Name

Maturity

Description and Notes

Geographic Coverage

[Multi-Value, Hierarchical]

Walk

Description — The geographic regions where the Service is offered or available. Aligned with the IF4IT Service Management Best Practices coverage and support model guidance.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Temporal and Effective Date attributes capture the dates that anchor each Service in time — its effective date and its next scheduled review date.

Attribute Name

Maturity

Description and Notes

Service Effective Date

Walk

Description — The date the Service became formally effective — typically the date the Service Definition was finalized and the Service moved to its first operational lifecycle state.

Benefit(s) — Provides historical anchor for Service tenure and evolution analysis. Supports audit and governance reporting.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Contractual and Legal attributes capture the contractual surface around each Service — the governing contract, its type, and whether audit rights are granted. For substantively contract-governed Services, these attributes connect the inventory to the Contracts and Agreements Inventory.

Attribute Name

Maturity

Description and Notes

Governing Contract Reference

Walk

Description — A reference to the contract that governs the Service — typically a Master Services Agreement, Statement of Work, EULA, Subscription Agreement, or internal MOU. References the planned Contracts and Agreements Inventory by Semantic ID.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Vendor and Supplier attributes capture the Vendor relationships for consumed Services — the primary Vendor and any subcontracted Vendors. These attributes connect the Services Inventory to the Vendors Inventory and support fourth-party risk visibility.

Attribute Name

Maturity

Description and Notes

Primary Vendor

Walk

Description — For consumed Services, the primary Vendor providing the Service. References the Vendors Inventory by Semantic ID.

Benefit(s) — Connects Services to Vendors in the Enterprise Model. Enables vendor concentration analysis at the Service level. Supports vendor risk management informed by Service-level dependency.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

IT Environment attributes capture the operating environments each Service runs in and its disaster recovery posture. These attributes connect the Services Inventory to environment governance and DR discipline.

Attribute Name

Maturity

Description and Notes

Operating Environments

[Multi-Value]

Walk

Description — The IT operating environments where the Service runs. References the planned Environments Inventory by Semantic ID.

Benefit(s) — Connects Services to environments. Supports environment-level impact analysis: when an environment is impacted, which Services are affected?

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Skills and Competencies attributes capture the workforce dependencies of each Service — the skills required to operate it and the operations team responsible. These attributes support workforce planning and skill-risk identification.

Attribute Name

Maturity

Description and Notes

Skills Required to Operate

[Multi-Value]

Walk

Description — The skills required to operate, support, or deliver the Service. Captures the workforce capability dependency.

Benefit(s) — Supports workforce planning informed by Service-level skill dependencies. Enables identification of Services at risk due to scarce skills.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Provenance and Audit attributes record the metadata about the inventory record itself — when it was created, by whom, when it was last updated, and when it was last audited. These attributes support inventory governance and audit discipline.

Attribute Name

Maturity

Description and Notes

Source of Record

Walk

Description — The authoritative system or document from which this Service record was sourced or with which it is synchronized.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Risk attributes capture the risk posture of each Service — its risk rating, whether it is a single point of failure, its business continuity plan reference, and related risk records. These attributes connect the Services Inventory to enterprise risk management.

Attribute Name

Maturity

Description and Notes

Service Risk Rating

Walk

Description — A composite risk rating for the Service, capturing the aggregate risk the Service represents to the enterprise.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Compliance and Regulatory attributes capture each Service’s compliance status, the regulations that apply, and the specific regulatory obligations. These attributes connect the Services Inventory to the compliance discipline.

Attribute Name

Maturity

Description and Notes

Service Compliance Status

Walk

Description — The current compliance status of the Service against applicable regulations and policies.

Benefit(s) — Provides compliance visibility at the Service level. Enables remediation prioritization. Supports regulatory reporting.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Financial attributes capture the cost and revenue dimensions of each Service — its cost model, annual cost, annual revenue (where applicable), and the responsible cost center. These attributes support Service portfolio financial analysis.

Attribute Name

Maturity

Description and Notes

Service Cost Model

Walk

Description — The cost structure of the Service — how the cost of providing or consuming the Service is structured.

Benefit(s) — Supports financial governance. Enables analysis of Service portfolio by cost structure.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Relationship attributes capture the cross-Service and cross-inventory relationships that position each Service in the Enterprise Model graph. These relationships enable graph traversal across the enterprise’s typed semantic surface and support impact analysis, dependency mapping, and portfolio reasoning.

Attribute Name

Maturity

Description and Notes

Service Group Membership

[Multi-Value]

Walk

Description — The Service Group(s) this Service belongs to. Service Groups organize related Services by fulfillment responsibility, service area, requester community, operational capability, or business context.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Services realize Capabilities. Every governed Service exists to make one or more Capabilities operationally available to a Service Requester Community. The Capability is the standing ability the enterprise possesses; the Service is the deliberate, contracted, governed offering through which that ability becomes accessible. The Services Inventory connects to the IF4IT Capabilities Inventory and Attributes through the Capability Realization attribute in the Strategic Attributes category.

A Capability without any Services realizing it is an unrealized strategic intent; a Service that does not realize a Capability is a misclassified activity. This relationship enables enterprise-wide analysis of which Capabilities are well-supported by Services, which are under-served, and where the Service portfolio is misaligned with Capability strategy. The relationship is many-to-many: one Capability may be realized by multiple Services (each realizing the Capability for a different Service Requester Community or through a different delivery model), and one Service may realize multiple Capabilities (where the Service contributes to several enterprise abilities).

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Applications enable Services. An Application is a software solution that runs in an operating environment to support one or more business or technical capabilities; a Service is a defined, governed offering that may be enabled by one or more Applications. The IF4IT Service Management Best Practices document is explicit that Applications are not automatically Services — the Application is an enabling asset, and the Service is the governed value-delivery offering it makes possible. The Services Inventory connects to the IF4IT Applications Inventory and Attributes through the Realizing Applications attribute in the Technical Attributes category.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Services consumed from external providers are sourced from Vendors. The Services Inventory connects to the IF4IT Vendors Inventory and Attributes through the Primary Vendor and Subcontracted Vendors attributes in the Vendor and Supplier Attributes category. This relationship is meaningful for any Service the enterprise consumes — SaaS subscriptions, cloud services, managed services, professional services — and is the foundation of Service-level Vendor concentration analysis.

The relationship enables joint analysis of Service portfolio and Vendor portfolio that neither inventory could support alone. Which Vendors deliver which Services to the enterprise? Which Services depend on a single Vendor whose disruption would cascade across multiple consumer communities? Which Vendors are concentrated in delivering Services for a single Capability or Service Group, creating concentration risk invisible from either inventory in isolation? The Subcontracted Vendors attribute extends this analysis to fourth-party risk — the Vendors that the enterprise’s Vendors depend on — supporting compliance with regulatory frameworks such as DORA, FCA Critical Third Parties, and APRA CPS 230 that require fourth-party visibility.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Services are governed by Contracts. The Contracts and Agreements Inventory is planned as part of the IF4IT Noun Type taxonomy — refer to the IF4IT Enterprise Inventory Management Best Practices document for its current definition. The Services Inventory anticipates this relationship through the Governing Contract Reference and Service Agreement Reference attributes in the Contractual and Legal Attributes category, and through the Related Contracts attribute in the Relationship Attributes category.

When the Contracts and Agreements Inventory is published, Contract records will reference the Service Semantic IDs they govern, and the Services Inventory will reflect these relationships in the Governing Contract Reference and Related Contracts attributes. This relationship enables compliance and contract teams to traverse from any Service to its governing contracts and from any contract to the Services it covers — the foundation for Service-level compliance management, contract renewal planning, and contract audit. For Services governed by multiple contracts (e.g., a Master Services Agreement plus a Data Processing Agreement plus a Business Associate Agreement), the Related Contracts attribute captures the full contractual surface.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Services and Products are peer offerings that may include, enable, or extend one another. The Products Inventory is planned as part of the IF4IT Noun Type taxonomy — refer to the IF4IT Enterprise Inventory Management Best Practices document for its current definition. The Services Inventory anticipates this relationship through the Related Products attribute in the Relationship Attributes category.

The conceptual boundary between Product and Service is settled by enterprise convention rather than IF4IT mandate. In many enterprises, a Product is a packaged offering with a SKU and a one-time or recurring consumption model, while a Service is an ongoing engagement with delivery and support obligations — but the same offering may legitimately be governed as both. A Microsoft 365 subscription is both a Product (a packaged offering) and a Service (an ongoing engagement). The Services Inventory and Products Inventory are designed to govern these reciprocally, with cross-references in both inventories rather than forcing a single classification.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Services participate in Value Streams. The Services Inventory connects to the IF4IT Value Streams Inventory and Attributes through the Value Stream Participation attribute in the Strategic Attributes category. A Value Stream is the stable, stakeholder-anchored flow of value through the enterprise; Services participate in Value Streams as the deliberate offerings the Value Stream exercises to produce its outcome.

The relationship is many-to-many: a Service may participate in multiple Value Streams (an IAM Authentication Service participates in nearly every Value Stream the enterprise operates), and a Value Stream may exercise multiple Services (a Hire-to-Productive Value Stream may exercise an Employee Onboarding Service, an Access Provisioning Service, a Training Service, and a Workspace Setup Service). This relationship enables Value Stream owners to understand which Services their stream depends on and Service Owners to understand which strategic flows their Service participates in.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Processes exercise Services. The Processes Inventory is planned as part of the IF4IT Noun Type taxonomy — refer to the IF4IT Enterprise Inventory Management Best Practices document for its current definition. The Services Inventory anticipates this relationship through the Related Processes attribute in the Relationship Attributes category.

The relationship is distinct from the Value Stream relationship. A Value Stream is the stable flow of value; a Process is the sequenced activity that operationalizes part of the Value Stream. A Process may exercise one or more Services as part of its sequencing, and a Service may be exercised by one or more Processes. This relationship enables joint Process and Service Management analysis: when a Process is redesigned, which Services are affected; when a Service is changed, which Processes are affected; where Process automation could substitute for human-delivered Services.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Incidents affect Services. The Incidents Inventory is planned as part of the IF4IT Noun Type taxonomy — refer to the IF4IT Enterprise Inventory Management Best Practices document for its current definition. An Incident is an unplanned interruption or degradation of Service; Service is the central reference point for Incident records. The Services Inventory anticipates this relationship through the Related Incidents attribute in the Relationship Attributes category.

When the Incidents Inventory is published, Incident records will reference the Service Semantic IDs they affect, and the Services Inventory will reflect these relationships in the Related Incidents attribute. This relationship enables Service Owners to understand Incident patterns for their Services, Service Managers to assess Service health based on Incident history, and Portfolio Owners to identify Services with disproportionate Incident frequency that may warrant redesign or replacement. Incident patterns at the Service level also feed Problem identification — recurring Incidents on the same Service often indicate an underlying Problem worth root-cause investigation.

Services Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

The Services Inventory and Attributes document is one of many Noun Type inventories in the IF4IT Enterprise Inventory Management taxonomy. Each inventory in the taxonomy governs a distinct class of enterprise asset, relationship, or organizational construct — and each contributes its records and relationships to the Enterprise Model that connects them all. The full catalog of recognized Noun Types, the principles that govern inventory design and federation, the Inventory of Inventories, and guidance for building, connecting, and maturing a complete enterprise inventory program are documented in the IF4IT Enterprise Inventory Management Best Practices document. Practitioners who find value in the Services Inventory are encouraged to explore the broader taxonomy — each additional inventory that is built and governed strengthens the Enterprise Model and expands the range of questions that AI-assisted enterprise analysis can answer. The IF4IT welcomes contributions from practitioners who develop attribute categories, attribute definitions, or governance approaches not covered in this document — your real-world experience is how this framework matures.