5.3 Other Service & Technical Practices

Other Service and Technical Practices

For the remaining practices you generally need to recall the purpose and, for a few, the headline distinction. These come from the service management family and the smaller technical management family (deployment management, plus infrastructure and platform management and software development and management).

Service Request Management

The purpose of service request management is to support the agreed quality of a service by handling all pre-defined, user-initiated service requests in an effective and user-friendly manner. A service request is a request from a user, or the user's authorized representative, that initiates a service action that has been agreed as a normal part of service delivery. Examples include a request for information, a request to provide a resource (such as a new laptop), a request for access to a resource, and feedback, compliments, or complaints.

The most important exam distinction: a service request is not an incident. An incident is an unplanned failure; a request is a normal, expected interaction. Because requests are predictable, they should be standardized and automated as far as possible, with pre-defined fulfilment procedures. Some requests need approvals (financial, security, or HR), and standardization enables self-service portals.

Monitoring and Event Management

The purpose of monitoring and event management is to systematically observe services and service components, and record and report selected changes of state identified as events. An event is any change of state that has significance for the management of a service or other configuration item. Monitoring can be active (polling components) or passive (receiving alerts). Events are typically classified into three types:

Monitoring is not the same as event management: monitoring watches; event management decides which changes of state matter and how to respond.

Service Configuration Management

The purpose of service configuration management is to ensure that accurate and reliable information about the configuration of services, and the configuration items that support them, is available when and where it is needed. A configuration item (CI) is any component that needs to be managed in order to deliver a service. Information is often held in a configuration management database (CMDB) or a wider configuration management system (CMS).

The practice must balance the cost and effort of collecting configuration data against the value that data provides — collecting everything is wasteful (keep it simple and practical).

IT Asset Management

The purpose of IT asset management (ITAM) is to plan and manage the full lifecycle of all IT assets to help the organization maximize value, control costs, manage risks, support decisions about purchase, reuse, retirement, and disposal, and meet regulatory and contractual requirements. An IT asset is any financially valuable component that can contribute to the delivery of an IT product or service.

The exam contrast: IT asset management tracks things with financial value (licences, hardware, cloud subscriptions), while service configuration management tracks things that must be controlled to deliver a service — an item can be both, but the two practices have different goals.

Deployment Management vs Release Management

These two are easy to confuse and are frequently tested together.

• The purpose of deployment management is to move new or changed hardware, software, documentation, processes, or any other component to live environments (and it may also move components to test or staging environments). Deployment is a technical management practice. Common deployment approaches are phased, continuous delivery, big bang, and pull.
• The purpose of release management is to make new and changed services and features available for use. A release is a version of a service or other configuration item, or a collection of configuration items, made available for use.

Key distinction: deployment = moving components into an environment; release = making a feature available to users. These can happen at different times. With feature flags or a dark launch, code is deployed to production but the feature is released later; conversely, a release can be made gradually to user groups after deployment. Remember the split:

• Move it to where it runs → deployment management.
• Let users actually use it → release management.

Common mistake to avoid: candidates often assume a release always equals a deployment, or that configuration management and asset management are the same practice. They are not. Deployment answers 'is the component in the environment?'; release answers 'can users use the feature?'. Service configuration management answers 'what is connected to what, and can we trust that information?'; IT asset management answers 'what do we own, what is it worth, and where is it in its financial lifecycle?'. Keeping these four purposes separate reliably earns marks on scenario questions that deliberately mix the vocabulary.

Across this section, match the trigger word to the purpose: 'pre-agreed user request' → service request management; 'change of state / event' → monitoring and event management; 'accurate CI information' → service configuration management; 'financially valuable asset lifecycle' → IT asset management; 'move a component to an environment' → deployment management; 'make a feature available for use' → release management.