Parent Process Reference Framework: ITIL 4
Service Value Stream Activities
Highly impacted Service Value System(SVS) Activities:
- Design and Transition
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.
item: Any component that needs to be managed in order to deliver an IT service
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.
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.
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.
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.
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.
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.
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
management typically needs processes
- 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.