Service configuration management (ITIL 4)

Parent Process Reference Framework: ITIL 4

Service Value Stream Activities

Highly impacted Service Value System(SVS) Activities:

• Obtain/build
• Design and Transition

Description

The purpose of the service configuration management practice is to ensure that accurate and reliable information about the configuration of services, and the CIs that support them, is available when and where it is needed. This includes information on how CIs are configured and the relationships between them.

Configuration item: Any component that needs to be managed in order to deliver an IT service

Configuration management provides information on the CIs that contribute to each service and their relationships: how they interact, relate, and depend on each other to create value for customers and users. This includes information about dependencies between services. This high-level view is often called a service map or service model, and forms part of the service architecture.

It is important that the effort needed to collect and maintain configuration information is balanced with the value that the information creates. Maintaining large amounts of detailed information about every component, and its relationships to other components, can be costly, and may deliver very little value. The requirements for configuration management must be based on an understanding of the organization’s goals, and how configuration management contributes to value creation.

The value created by configuration management is indirect, but enables many other practices to work efficiently and effectively. As such, planning for configuration management should start by understanding who needs the configuration information, how it will be used, what is the best way for them to obtain it, and who can maintain and update this information. Sometimes it can be more efficient to simply collect the information when it is needed, rather than to have it collected in advance and maintained, but on other occasions it is essential to have information available in a configuration management system (CMS). The type and amount of information recorded for each type of CI should be based on the value of that information, the cost of maintaining it, and how the information will be used.

Configuration information should be shared in a controlled way. Some information could be sensitive; for example, it could be useful to someone trying to breach security controls, or it could include personal information about users, such as phone numbers and home addresses.

Configuration information can be stored and published in a single configuration management database (CMDB) for the whole organization, but it is more common for it to be distributed across several sources. In either case it is important to maintain links between configuration records, so that people can see the full set of information they need, and how the various CIs work together. Some organizations federate CMDBs to provide an integrated view. Others may maintain different types of data; for example, having separate data stores for asset management data (see section 5.2.6), configuration details, service catalogue information, and high-level service models.

Tools that are used to log incidents, problems, and changes need access to configuration records. For example, an organization trying to identify problems with a service may need to find incidents related to a specific software version, or model of disk drive. The understanding of the need for this information helps to establish what CI attributes should be stored for this organization; in this case software versions and disk drive models. To diagnose incidents, visibility of recent changes to the affected CIs may be needed, so relationships between CIs and changes must be maintained.

Many organizations use data collection tools to gather detailed configuration information from infrastructure and applications, and use this to populate a CMS. This can be effective, but can also encourage the collection of too much data without sufficient information on relationships, and how the components work together to create a service. Sometimes configuration information is used to actually create the CI, rather than just to document it. This approach is used for ‘infrastructure as a code’, where information on the infrastructure is managed in a data repository and used to automatically configure the environment.

A large organization may have a team that is dedicated to configuration management. In other organizations this practice can be combined with change control, or there can be a team responsible for change, configuration, and release management. Some organizations apply a distributed model where functional teams take ownership of updating and maintaining the CIs within their control and oversight.

Configuration management typically needs processes to:

• identify new CIs, and add them to the CMS
• update configuration data when changes are deployed
• verify that configuration records are correct
• audit applications and infrastructure to identify any that are not documented.