Define what a service is and what it is not

Overview

In many organizations, the word “service” is used to describe many different things at the same time. A help desk ticket is called a service. A software application is called a service. A business process is called a service. A team’s general availability to answer questions is called a service. When everything is treated as a service, the term loses its usefulness as a governance, management, and operating construct.

This definitional ambiguity is one of the most common root causes of poor service governance, inconsistent service delivery, weak ownership, unreliable service reporting, and failed Service Catalog implementations. A Service Management practice cannot be effective unless the organization has a clear, shared definition of what qualifies as a service and what does not.

Best Practice

Establish and publish a clear, organization-wide definition of what a service is, what it is not, and how it differs from related concepts such as applications, processes, requests, teams, systems, platforms, and support activities. For example…

A service is a defined capability or offering that an organization provides to a defined customer, consumer, requester, or stakeholder to help them achieve a specific goal or outcome. A governed service should have clear boundaries, an identifiable customer or consumer, accountable ownership, a value proposition, expected outcomes, and a defined means of request, fulfillment, delivery, or consumption.

A service is not unlimited. It is not for everyone. It is not ownerless. It does not exist merely because a team performs work, an application exists, a process is executed, or a technology component is available. If something does not meet the organization’s service criteria, it should not be listed in the Service Catalog as a governed service.

The service customer or consumer of a service can be human, organizational, or technical. The fulfiller of a service can also be human, technical, or a combination of both. This means that Service Management should be broad enough to account for both human-delivered services and technology-delivered services, while still applying consistent service definition standards.

Examples of primarily human-delivered services include, but are not limited to:

• Strategy Development Services, such as Enterprise Architecture Services

• Planning and Execution Services, such as Program and Project Management Services

• Software Development Services

• Quality Assurance Services

• Change Management Services

• Administration, Operations, and Support Services

• Incident Recovery Services

• Disaster Recovery Services

• Employee and Consultant Onboarding Services

• Employee and Consultant Termination Services

Examples of primarily technology-delivered services include, but are not limited to:

• API-based services that provide request/response or request/action capabilities

• Ephemeral computing services that perform a defined function and then shut down

• Batch processing services that execute scheduled or event-driven work

• Data processing, transformation, or synchronization services

• Automated notification, validation, monitoring, or workflow services

Service Definition and Execution Pattern:

Although services may vary in form, many services follow a common request-and-fulfillment pattern. This pattern helps distinguish a true service from a general activity, asset, application, or organizational function.

The expanded pattern also clarifies the operating model around the service. The Service Desk or Help Desk is the practical engagement and coordination point that receives Service Requests, creates or updates Service Records, routes work to the Service Provider workforce, manages communications, and helps ensure fulfillment remains visible. The Service Provider workforce fulfills standard requests, while Subject Matter Expert teams handle complex, specialized, high-risk, or exception-based requests that require deeper domain knowledge.

These fulfillment and escalation paths should be defined as part of the Service Definition so ownership, handoffs, Service Expectations, Service Records, customer communications, and Service Governance remain controlled. Every governed service should also be registered in an authoritative Service Inventory and, where it is requestable or consumable by a requester community, exposed through the Service Catalog or another approved Service Engagement Channel. The Service Inventory supports governance, ownership, lifecycle management, reporting, and auditability; the Service Catalog supports discovery, understanding, request initiation, and customer-facing service consumption.

This principle applies across the enterprise root Service Portfolio and all child Service Portfolios, not only within a single team, domain, or catalog tool. Portfolio-specific service lists may be useful management views, but they should roll up into the enterprise Services Inventory so leaders, Service Owners, Service Managers, Portfolio Owners, and governance teams can understand the complete service landscape.

The Service Definition & Execution Pattern can be depicted as a combination of all its definition components organized in a logical “Definition + Request + Fulfillment” sequence:

1. Service Expectations — A set of predefined requirements provided by a Service Owner for how a Service will be structured, enabled and performed in a manner that guarantees measurable, predictable, and acceptable results. Such expectations are commonly composed of three sub-components or traits known as Service Indicators, Service Objectives, and Service Agreements.

2. Service Requester — A person, organization, or system that requests or consumes the service (a.k.a. the Service Customer or Customer).

3. Service Request — A specification, instruction, trigger, input, or set of criteria submitted by the Service Requester to initiate the Service. A Service Request is also informally known as a Service Ticket (or, informally a Ticket), which is simply a data structure that is used to register the request and act upon it (i.e., update it, reroute it, close it, etc.).

4. Service Provider (a.k.a. Service Actor) — The person, team, system, application, automation, or technology that performs the work needed to fulfill the Service Request. For example, the person who works at the Service Desk / Help Desk.

5. Service Action — The work performed by one or more Service Providers in response to the Service Request.

6. Service Outcome — The result produced by the Service Provider according to the predefined set of Service Expectations. A Service Outcome may include a Service Response, deliverable, completed transaction, changed state, notification, record update, or other measurable result.

7. Service Desk / Help Desk Coordination — The approved operating function or engagement channel that receives Service Requests, creates or updates Service Records, routes work, communicates status, coordinates fulfillment, and helps maintain visibility into request handling.

8. Service Provider Workforce and Escalation Path — The teams, roles, systems, vendors, or Subject Matter Expert teams that fulfill standard requests, handle specialized work, resolve complex conditions, and complete the actions needed to produce the Service Outcome.

9. Service Governance Registration — The act of registering the governed service in the enterprise Services Inventory, the authoritative record for governed services across the enterprise root Service Portfolio and all child Service Portfolios, and, where appropriate, exposing it through the Service Catalog or another approved Service Engagement Channel.

Service Registration and Exposure:

Services can be registered, exposed, requested, invoked, and consumed through different constructs.

Human-engaged services are commonly registered in and exposed through a Service Catalog, portal, request system, workflow platform, or support channel. Technology-engaged services are commonly registered in and exposed through technical platforms such as API catalogs, API gateways, service registries, ephemeral computing platforms, workflow engines, event-processing systems, batch processing systems, and automation platforms.

The registration and exposure mechanism should match the nature of the service. A consulting service, onboarding service, API service, batch service, and event-driven automation service may all be valid services, but they should not necessarily be described, requested, governed, measured, or operated in exactly the same way.

An Important Distinction Is That Applications Are Not Automatically Services:

Be careful when classifying an application as a service. An application may enable, expose, automate, or participate in many services (sometimes thousands), but the application itself is not automatically a service.

An application is typically a software solution that runs in an operating environment to support one or more business or technical capabilities that are implemented as in-application services. It may provide user interfaces, APIs, data processing, workflow, reporting, integrations, or automation. However, the application as a whole may not have the same boundaries, requester, request, actor, action, outcome, service level, or consumption pattern that define a governed service.

For example, an enterprise application may support onboarding services, account management services, reporting services, data validation services, approval services, notification services, and support services. In this case, the application is better understood as an enabling solution or service platform, while the services it enables should be defined, owned, cataloged, governed, and measured individually where appropriate.

This distinction prevents organizations from overloading the Service Catalog with applications, platforms, systems, and technical assets that do not represent discrete consumable services. It also helps clarify service ownership, operational support, cost allocation, customer expectations, performance measurement, and continual improvement.

For related guidance on governing applications as managed assets and understanding how applications enable services, see Application Portfolio Management (APM) Best Practices.

Benefit(s)

A clear service definition creates the foundation for effective Service Management.

Governance becomes possible because there is a shared understanding of what is being governed. Ownership becomes meaningful because there is a shared understanding of what is being owned. Service Catalog entries become more trustworthy because only offerings that meet the organization’s service criteria are listed as services. Reporting becomes more accurate because services, applications, processes, requests, and assets are not incorrectly blended together.

Definitional clarity is one of the highest-leverage investments an organization can make in its Service Management capability. It improves service modeling, catalog design, ownership assignment, performance measurement, funding decisions, operational accountability, customer expectations, and continual service improvement.