Services Inventory and Attributes

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.

Benefit(s) — Enables unambiguous cross-inventory referencing — Capabilities, Applications, Technologies, Contracts, Vendors, Service Records, and Incidents all reference Services by Semantic ID. Enables AI-assisted cross-inventory traversal without ETL transformation. Makes reclassification seamless: the identifier travels with the record through any category, lifecycle, or ownership change.

Source — Manual.

Examples — SVC-ONBOARDING-EMPLOYEE, SVC-ACCESS-PROVISIONING, SVC-API-CUSTOMER-LOOKUP, SVC-DESKTOP-SUPPORT, SVC-EMAIL-DELIVERY

Notes — Recommended convention: SVC-{ShortServiceName}. Permanent once assigned — must not change even if the Service is renamed, transferred to a new Owner, or moved to a different Service Group or Service Portfolio. Never reused after the Service is retired.

Description — The display name of the Service as it appears in the Service Catalog, in governance reporting, and in cross-inventory references.

Benefit(s) — Provides a consistent human-readable identifier independent of the Semantic ID. Enables practitioners to find and recognize the Service without needing to know its formal identifier.

Source — Manual.

Examples — Employee Onboarding, Customer API Access, Desktop Support, Email Delivery

Notes — Use Title Case. Avoid acronyms in the Service Name unless the acronym is the universally recognized form of the Service. Avoid version numbers in the Service Name; Service versions are governed through the Lifecycle Status and replacement attributes, not through the name.

Description — The formal definition of what the Service is, who it serves, what it consumes, and what it produces. Composed by the Service Owner per the IF4IT Single Service Definition Pattern. The Service Definition Statement is the authoritative answer to the question "What is this Service?"

Benefit(s) — Eliminates definitional ambiguity. Provides the foundation against which Service Catalog entries, Service Engagement Channel content, Service Records, and Service Reports are all validated. Establishes the boundary between what the Service does and what it does not do.

Source — Manual.

Examples — "Employee Onboarding provisions all access, equipment, and training required for a new employee to begin productive work on day one, fulfilled by IT, HR, Facilities, and Security in coordinated sequence." "Customer API Access provides external customer applications with authenticated, rate-limited access to the customer-record query API."

Notes — Should be 1-3 sentences. Should name the Service Requester Community (who the Service is for), the Service Outcome (what the Service produces), and the boundary (what the Service does not do where boundary confusion is likely). Refer to the IF4IT Service Management Best Practices document for the Service Definition discipline.

Description — A plain-language description of the Service for practitioners who need broader context than the Service Definition Statement provides. Expands on the Service Definition Statement with operational context, common consumption patterns, typical Service Outcomes, and the value the Service delivers.

Benefit(s) — Provides context for practitioners reviewing the Service record without requiring lookup of related records. Supports onboarding new Service Owners, Service Managers, and Service Providers who need to understand the Service quickly.

Source — Manual.

Notes — May be longer than the Service Definition Statement. Should complement, not duplicate, the Service Definition Statement. Should not include performance commitments or governance terms — those belong in the Service Expectations attributes.

Service Inputs

[Multi-Value]

Description — What flows into the 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: short labels or brief prose at the practitioner’s discretion.

Benefit(s) — Makes the Service’s input dependencies legible at a glance. Enables impact analysis: when an input source changes, fails, or is retired, which Services are affected? Aligns with the IF4IT Single Service Definition Pattern, which lists Inputs as the fourth element of a complete Service Definition.

Source — Manual.

Examples — "Customer master records from the CRM; transaction events from the order pipeline; authentication tokens from the enterprise SSO" or "API request payloads validated against the published OpenAPI schema"

Notes — Use semicolons to separate distinct input categories where prose enumeration is the form chosen. For Services with formal interface specifications, point at the specification document in Notes rather than enumerating every field. The intent is governance-level legibility, not field-level technical specification.

Service Outputs

[Multi-Value]

Description — What flows out of the 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: short labels or brief prose at the practitioner’s discretion.

Benefit(s) — Makes the Service’s output dependencies legible at a glance. Enables impact analysis: when a Service changes its outputs, which downstream consumers are affected? Aligns with the IF4IT Single Service Definition Pattern, which lists Outputs as the fifth element of a complete Service Definition.

Source — Manual.

Examples — "Provisioned user accounts in the target Application; access entitlement records in the IAM system; notification to the requester’s manager" or "API response payloads conforming to the published response schema; audit log entries"

Notes — Distinct from Service Outcomes (which describe the result for the Service Requester) — Service Outputs describe what the Service emits or changes regardless of who ultimately receives it. Use semicolons to separate distinct output categories.

Description — The articulation of the value the Service delivers to its Service Requester Community — why the Service exists, what the consumer gains from it, and what becomes possible because of it. The IF4IT Service Management Best Practices document treats the Value Proposition as a defining attribute of a managed Service.

Benefit(s) — Connects the Service to strategic intent. Enables Portfolio Owners to evaluate the Service against the value it claims to deliver. Provides Service Owners with a defensible articulation of the Service’s reason for being when investment, lifecycle, or rationalization decisions are made.

Source — Manual.

Examples — "Reduces new-employee time-to-productivity from two weeks to one day by automating the coordination of access, equipment, and training across IT, HR, Facilities, and Security."

Notes — Should be written from the Service Requester’s perspective, not the Service Provider’s perspective. A Value Proposition that describes the work the Service Provider does is not a Value Proposition — it is a description of the work.