Service Management Best Practices

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.

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 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.

Figure: The Anatomy of a Governed Service — A governed service is more than a task, application, team, or technology component. It has defined boundaries, accountable ownership, a customer or consumer, service expectations, a request-and-fulfillment pattern, a measurable outcome, and a clear value proposition. These characteristics distinguish true services from the assets, processes, platforms, and technologies that may enable them.

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.

Common service traits include:

1. Service Level Agreement (SLA), Service Level Objective (SLO), or Service Expectation — A predefined set of requirements, commitments, targets, or expectations that describe how the service is expected to perform or be fulfilled.

2. Service Requester — A person, organization, system, application, or technology component that requests or consumes the service.

3. Service Request — A specification, instruction, trigger, input, or set of criteria submitted by the Service Requester to initiate the service.

4. Service Actor — The person, team, system, application, automation, or technology that performs the work needed to fulfill the Service Request.

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

6. Service Outcome — The result produced by the Service Action according to the specifications, criteria, or expectations of the Service Request. A Service Outcome may include a Service Response, deliverable, completed transaction, changed state, notification, record update, or other measurable result.

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.

Figure: Services vs. Enabling Constructs — Applications, APIs, workflows, platforms, databases, infrastructure, teams, processes, and data may all enable or participate in service delivery, but they are not automatically services. A governed service has defined boundaries, a customer or consumer, a request or trigger, fulfillment by actors, a measurable outcome, accountable ownership, service expectations, and a clear value proposition. This distinction helps prevent Service Catalogs from becoming cluttered with enabling assets that should be governed, managed, and measured differently from the services they support.

Important Distinction: 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, 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. 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.

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.