1. About this document
It is split into five main sections, covering:
- general information about the practice
- the practice’s processes and activities and their roles in the service value chain
- the organizations and people involved in the practice
- the information and technology supporting the practice
- considerations for partners and suppliers for the practice.
2. General information
2.1 Purpose and description
Key message
The purpose of the service configuration management practice 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. This includes information on how configuration items are configured and the relationships between them.
Organizations use resources to create and deliver products and services. These resources may belong to the organization, or they may be available as part of a service the organization consumes. The service configuration management practice collects and manages information about a variety of resources, typically including hardware, software, networks, buildings, people, suppliers, products, services, and documentation. The resources in the scope of the practice are called configuration items (CIs).
Definition:Configuration item
Any component that needs to be managed in order to deliver an IT service.
The primary objective of the service configuration management practice is to efficiently provide useful information to the organization. The scope of the components under its control should be defined by their usefulness and efficiency. The main factors shaping this practice are the usefulness of the configuration information and the costs of obtaining and maintaining it.
Tips
Resources that cannot be individually managed are usually not considered CIs. For example, the knowledge used by an analyst to manage incidents is important but will probably not be treated as a CI. At the same time, virtual resources, such as a virtual server or network, may be CIs and require similar management as physical resources.
The service configuration management practice is focused on resources that are important for product and service management, regardless of whether these resources are the organization’s property or provided as part of a third-party service. Different lifecycle models and controls may apply to these two groups of resources (see section 2.2.2).
The service configuration management practice involves identifying and documenting the connections and relationships between configuration items. This usually results in models (known as service configuration models, service resourcing models, or functional and financial service models). These models can be focused on various aspects of the service architecture and the relationships between the components. They represent various level of abstraction, from high-level functional models (as shown in Figure 2.1) to an accurate mapping of the connections and relationships between physical and digital CIs.
Service configuration models are used in various ways, including for:
- impact analysis
- cause and effect analysis
- risk analysis
- cost allocation
- availability analysis and planning.
Service configuration models should be designed and maintained to meet stakeholder needs.
The service configuration management practice is a highly-automated practice. It relies on the collection, maintenance, and control of large amounts of configuration data and often includes building, maintaining, and presenting complex configuration models. The practice involves gathering data from multiple sources, integrating it and presenting in a meaningful way. Specialized tools are typically used alongside monitoring, discovery, analytical, and record-keeping systems.
This practice often allows configuration information to integrate with records that are managed as part of other practices, including the incident management, change enablement, problem management, monitoring and event management, and service request management practices, among others. However, some configuration models are difficult or impossible to automate; they require manual data maintenance and/or relationship mapping. Examples include user data, organizational structures, contracts with suppliers and partners, and so on. Manual efforts and associated costs, alongside automation and integration costs, should be considered when the practice is being designed and improved.
2.2 Terms and concepts
2.2.1 CI categorization
The service configuration management practice is mostly focused on the following types of resources:
- information and technology:
- equipment and devices of all types
- applications and information systems, including master copies and distributives, individual installations, licenses, source code and code artefacts, and so on
- virtual infrastructure, including images, configuration scripts, machines, networks, machine monitors, and so on
- databases and data, including documented knowledge artefacts, records, and reports
- suppliers and contracts:
- services
- service catalogues and service offerings
- contracts and agreements
- records and reports
- key contacts
- locations
- organizations and people
- organizational units
- locations
- employees, roles, and contacts
- value streams and processes
- documented value streams, processes, and procedures.
These and other relevant resources are usually mapped to each other and to the organization’s products, product offerings, and services. Configuration information also may include:
- service consumers and their resources relevant to the organization’s services, including
- customers
- users
- locations
- organizational units
- information and technology
- service agreements and other relevant documentation.
CIs of different types have different key attributes, and they may have different lifecycle stages and different levels of control from the organization. These differences are usually reflected in the way information about the CIs is collected, stored, controlled, and presented throughout their lifecycles.
Configuration information about CI groups or types may be managed as well as individual CIs. For example, a known error in a particular model of equipment or version of application is likely to be a group attribute cascaded down to every CI that belongs to the group.
2.2.2 CI models
CI lifecycle models standardize, optimize, and (where possible) automate CI information handling. CI lifecycle models define, for a particular type of CIs:
- CI type owner(s)
- naming and labelling, if applicable
- key group and individual attributes
- key relationships (taxonomic and functional)
- key lifecycle stages
- procedures and/or guidelines for CI identification, ongoing control, verification, and audit
- responsibility for following the model
- key stakeholders (interested in the configuration information) and their requirements
- key reports and dashboards presenting the configuration information, where applicable.
The CI type owner, who typically manages resources and is often known as the resource owner or manager), is responsible for developing and maintaining the CI models.
2.2.3 Service configuration management in digital environments
Because of the growing adoption of digital infrastructure solutions (such as infrastructure-as-a-code, virtual machines and networks, and various cloud services), new types of CIs and CI relationships have emerged. For example, information about relationships between hardware servers and the virtual machines running on them may be relevant in the context of a service model and therefore expected to be provided through the service configuration management practice.
These relationships are usually managed by virtual machine monitor (VMM, also known as Hypervisor) systems. However, there is some debate about whether this information should be obtained directly from the VMM system or imported into the configuration management system (CMS). Similar practical questions are applicable to virtual networks, environment configuration scripts, and other means of virtual solutions management.
There is no correct answer and no recommended solution for defining which resources should be under the service configuration management practice’s control. These decisions should be driven by key factors: the usefulness of the configuration information to stakeholders and the costs of obtaining and maintaining the information.
For example, if the only stakeholders interested in the relationships between virtual machines and servers are the administrators of these servers and virtual machines, investing in the close integration of the VMM data into the CMS is not worthwhile, as the key stakeholders can access the information they need directly from the VMM system. However, if other stakeholders need this data and the costs are justifiable, the required data will likely be integrated with the CMS.
2.2.4 Configuration management systems and databases
The service configuration management practice involves a significant amount of data from various sources and depends on the ability to collect, integrate, process, and present this data in a reliable, cost-efficient way. CMSs are designed to fulfil this need. Because of the multiplicity of data sources for the practice, a CMS is usually a complex system that combines one or more specialized solutions and integrations with sources of configuration data.
Definition: Configuration management system
A set of tools, data, and information that is used to support the service configuration management practice.
A key functionality of a CMS is keeping and managing CI records and the relationships between them. This is usually achieved with one or more configuration management databases (CMDBs).
Definition: Configuration management database
A database used to store configuration records throughout their lifecycle. It also maintains the relationships between configuration records.
Sometimes the terms ‘CMS’ and ‘CMDB’ are used interchangeably, usually in accordance with the CMS definition.
2.2.5 CI verification and audit
As an important source of information for decision-making, CI records and configuration models are subject to continual verification and regular audits.
Service configuration data should:
- reflect the actual attributes, statuses, and relationships of the CIs
- highlight deviations from the baseline configuration(s)
- provide sufficient data to restore or re-create the approved configuration(s).
Definition: Baseline configuration
A configuration of a product, service, or infrastructure that has been formally reviewed and agreed. It serves as the basis for further activities, such as use, development, and planning.
The service configuration management practice ensures that relevant CI data is captured in the CMDB at each stage of the lifecycle. The practice should ensure that changes in CIs are correctly and promptly captured in the CMDB. To that end, CI record-keeping should be automated wherever possible. Automation improves the reliability of the configuration data and decreases the need for verification (but does not remove it).
Definition: Verification
An activity that ensures that a new or changed IT service, process, plan, or other deliverable matches its design specification and is complete, accurate, and reliable.
In this practice, verification is a continual activity of identifying and correcting gaps and deviations between the data in CMDB and the actual environment and/or the approved configurations. In many cases, verification can be largely automated, such as checking CMDB data (including CIs and relationships) for completeness, correctness, and compliance.
Definition: Inventory
Data collection and clean-up performed to build or verify CMDB data.
Depending on the CI types that are in scope and the available automation tools, inventory is performed manually or through integration with discovery tools and other systems that are collecting data about the status of the organization’s resources. The CMDB indicates what should be found, and the inventory reveals what is found. The identification and resolution of gaps between the CMDB and the inventory is verification. When verifying data, it may help to:
- identify and investigate unregistered CIs found in the organization
- identify and document unregistered authorized changes (typically indicating ineffective CI control)
- identify, investigate, and revert or otherwise address unauthorized changes.
There are different approaches to dealing with identified gaps between the actual and documented configuration information. The key challenge is to ensure that the data in the CMDB reflects the status of the organization’s resources and that this status is correct (meaning there are no unauthorized changes). Possible solutions include:
- carefully investigating every finding and correction of the organization’s resources or configuration data, depending on the investigation’s results
- (semi-)automatically updating the CMDB to reflect the de-facto situation, regardless of whether the situation is authorized (this decouples the investigation of unauthorized changes from the CMDB verification)
- (semi-)automatically correcting the de-facto situation based on the latest configuration baseline, without investigating the gaps’ origins (this is more applicable to digital resources and can be difficult to do with physical resources).
These solutions are not mutually exclusive. They can be combined as necessary, depending on the situation.
Organizations may also formally audit configuration data. These audits are often combined with IT asset audits (see the IT asset management practice guide).
Definition: CMDB audit
A planned, structured, and documented inspection of the organization’s configuration items that aims to assess the correctness of the CMDB data in scope.
Auditing is one of the tools of CMDB verification; a resource-demanding planned verification endeavour. It is usually organized and managed as a project and, like any project, should be justified and approved in order to occur.
Verification is an integral part of the service configuration management practice. It is necessary in order to ensure that the configuration data is valid and reliable.
2.3 Scope
For the chosen types of CIs, the service configuration management practice ensures that:
- trustworthy configuration data is provided and maintained, which includes updating the configuration data to reflect ongoing changes in the statuses, attributes, and relationships of CIs
- relevant and accurate reports are provided to support decision-making
- the CI lifecycle is integrated with other practices.
There are several activities and areas of responsibility that are not included in the service configuration management practice, although they are still closely related to service configuration management. In some cases, the practice depends on these activities. They are listed in Table 2.1, along with references to the practices in which they can be found. It is important to remember that ITIL practices are merely collections of tools to use in the context of value streams and should be combined as necessary, depending on the situation.
Table 2.1 Activities related to the service configuration management practice described in other practice guides
| Activity | Practice guide |
|---|---|
| Managing IT assets and IT asset data | IT asset management |
| Managing contracts with suppliers and partners | Supplier management |
| Ensuring that only authorized changes are made to CIs | Change enablement |
| Defining and managing the architectures of the organization’s products and services | Architecture management |
2.4 Practice success factors
Definition: Practice success factor
A complex functional component of a practice that is required for the practice to fulfil its purpose.
A practice success factor (PSF) is more than a task or activity, as it includes components of all four dimensions of service management. The nature of the activities and resources of PSFs within a practice may differ, but together they ensure that the practice is effective.
The service configuration management practice includes the following PSFs:
- ensuring that the organization has relevant configuration information about its products and services
- ensuring that the costs of providing configuration information are continually optimized.
2.4.1 Ensuring that the organization has relevant configuration information about its products and services
The focus of the service configuration management practice is ensuring that relevant configuration information is captured, maintained, and provided to the stakeholders when needed.
Typically, stakeholders that benefit from configuration information use it in the contexts of other management practices and in the wider context of the organization’s value streams.
As is listed in section 2.1, the key purposes of configuration information include:
- impact analysis
- cause and effect analysis
- risk analysis
- cost allocation
- availability analysis and planning.
Table 2.2 provides some examples mapping these purposes to management practices. These and other ways to use configuration information are applicable to every practice and value stream. However, in every case there should be a justification for adding more data or complexity to the CMDB. Key questions to consider include:
- Is this information available from other sources?
- Is this information critical or optional for decision-making?
- What are the initial and ongoing costs of including this information in the CMDB?
- How often is this information required?
- How soon does it need to be available?
Table 2.2 Mapping purposes to management practices
| Impact analysis | Cause and effect analysis | Risk analysis | Cost allocation | Availability analysis and planning | |
|---|---|---|---|---|---|
| Incident management | Analysis of the impacts of incidents on resources, products, services, and users | Localization of failed CIs based on information about their impacts | Analysis of the expected impacts of developing incidents | Allocation of costs of supporting cost centres and/or customers | Assessment of service availability during incidents and workaround planning |
| Problem management | Analysis of the impacts of errors on resources, products and services, service consumers, and users | Identification of CIs and relationships that might cause or have caused incidents | Analysis of the potential impacts and probabilities associated with identified errors | Allocation of problem investigation and control to cost centres and/or customers | Assessment of the impacts of identified errors on service availability and the planning of temporary solutions |
| Change enablement | Analysis of the impacts of ongoing and planned changes on resources, products and services, service consumers, and users | Review of unsuccessful changes and changes with unplanned effects, as well as the identification of possible causes of failures | Analysis of risks during the planning of changes | Allocation of costs of changes to cost centres and/or customers | Assessment of the impacts of planned changes on service availabilityPlanning of service availability during planned changes |
| Availability management | Analysis of the impacts of events and changes on the availability of resources, and products and servicesAnalysis of the impacts of unavailable resources on products and services | Identification of causes of product and service unavailability | Analysis of (un)availability risks | Allocation of costs of enhanced availability measures to cost-centres and/or customers | Analysis and planning of product and service availability |
| Service continuity management | Analysis of the impacts of possible and actual disasters on resources, and products and servicesAnalysis of the impacts of the unavailability of resources on vital business functions | Identification of causes of disasters | Analysis of service continuity risks | Allocation of the costs of enhanced availability measures to cost-centres and/or customers | Analysis and planning of product and service availability |
| Information security management | Analysis of the impacts of security events, incidents, and vulnerabilities on resources and products and services | Identification of the causes of information security incidentsIdentification of vulnerabilities | Analysis of information security risks | Allocation of the costs of information security controls to cost-centres and/or customers | Analysis and planning of product and service information security |
In some cases, it is more efficient to retrieve configuration data upon request than to make it permanently available.
These considerations apply to a range of CI types, attributes, relationships, and lifecycle stages.
Key message
Configuration information should be relevant to the organization’s needs. Including all available data in a CMDB or blindly following examples from other organizations is not beneficial. The service configuration management practice is only as valuable as the information it provides is accurate, up to date, reliable, understandable, easy to use, and relevant.
Collecting, managing, and providing configuration information are activities that cannot be performed in an isolation. It is important to ensure that the relevant elements of the service configuration management practice are included in the organization’s value streams and consistently applied in line with the organization’s approach to service configuration management.
Following the optimize and automate guiding principle, routine tasks, such as discovery, inventory, verification, should be optimized and automated to streamline workloads and improve the practice effectiveness and efficiency.
In line with the keep it simple and practical guiding principle, the service configuration management practice should not become a bureaucratic control system. Rather, it should streamline work by providing valuable information in a convenient, useful form. This provision of information typically involves channels managed as part of other practices (including the supplier management and service desk practices). The effective integration of practices is essential for the configuration information consumers to have a positive experience.
2.4.2 Ensuring that costs of providing configuration information are continually optimized
The service configuration management practice provides information to other practices, acting as a supporting practice in most of the organization’s value streams. However, it is unlikely that it will contribute to a value stream with core value-creating activities. This means that it is important to ensure that the cost of configuration information is continually optimized.
Cost optimization can be achieved in multiple ways, but a good way to drive optimization is to follow the ITIL guiding principles, as described in Table 2.3.
Table 2.3 ITIL guiding principles and the continual optimization of configuration information costs
| Guiding principles | Description |
|---|---|
| Focus on value | Include only the relevant information required by stakeholders |
| Start where you are | Use available sources of information; avoid adding new sources and tools unless they are justified |
| Progress iteratively with feedback | Regularly review information use and confirm its relevance, adjusting the CMDB scope if needed |
| Collaborate and promote visibility | Explain and promote available sources of configuration information and the best ways to use them, then provide hints and tips for more efficient use |
| Think and work holistically | Consider other sources of data for decision-making, do not try to put everything in the CMDB |
| Keep it simple and practical | Provide relevant information in the most convenient way; avoid complex interfaces and reports |
| Optimize and automate | Continually optimize resource-consuming practice activities. Automate CMDB verification, data collection, relationship discovery, and other activities. |
2.5 Key Metrics
The effectiveness and performance of ITIL practices should be assessed within the context of the value streams to which each practice contributes. As with the performance of any tool, the practice’s performance can only be assessed within the context of their application. However, tools can differ greatly in design and quality and these differences define a tool’s potential or capability to be effective when used according to its purpose. Further guidance on metrics, key performance indicators (KPIs), and other techniques that can help with this can be found in the measurement and reporting practice guide.
Key metrics for the service configuration management practice are mapped to its PSFs. They can be used as KPIs in the context of value streams to assess the contribution of the practice to the effectiveness and efficiency of those value streams. Some examples of this are given in Table 2.4.
Table 2.4 Examples of key metrics for the practice success factors
| Practice success factors | Key metrics |
|---|---|
| Ensuring that the organization has relevant configuration information about its products and services | Stakeholder satisfaction with configuration information Stakeholder satisfaction with service configuration management interfaces, procedures, and reports Number and impact of bad decisions made due to insufficient or incorrect configuration information Number and impact of incorrect data in the CMDB Percentage of CMDB data verified over the period |
| Ensuring that the costs of providing configuration information are continually optimized | The direct costs of service configuration management |
The correct aggregation of metrics into complex indicators will make it easier to use the data for the ongoing management of value streams, and for the periodic assessment and continual improvement of the service configuration management practice. There is no single best solution. Metrics will be based on the overall service strategy and priorities of an organization, as well as the goals of the value streams to which the practice contributes.
3. Value Streams and processes
3.1 Value streams contribution
Like any other ITIL management practice, the service configuration management practice contributes to multiple value streams. It is important to remember that a value stream is never formed for a single practice. The service configuration management practice combines with other practices to provide high-quality services to consumers. The main value chain activities to which the practice contributes are
- deliver and support
- design and transition
- obtain/build
- improve.
The contribution of the service configuration management practice to the service value chain is shown in Figure 3.1.
3.2 Processes
Each practice may include one or more processes and activities that may be necessary to fulfil the purpose of that practice.
Definition: Process
A set of interrelated or interacting activities that transform inputs into outputs. A process takes one of more defined inputs and turns them into defined outputs. Processes define the sequence of actions and their dependencies.
Service configuration management activities form three processes:
- managing a common approach to service configuration management
- capturing, managing, and providing configuration information
- verifying configuration data.
3.2.1 Managing a common approach to service configuration management
This process is focused on establishing an effective and efficient approach to the management of configuration information in the organization. It includes the activities listed in Table 3.1 and transforms the inputs into outputs.
Table 3.1 Inputs, activities, and outputs of the managing a common approach to service configuration management process
| Key inputs | Activities | Key outputs |
|---|---|---|
| Organizational architecture Stakeholder requirements Organizational structure Organization’s portfolios Monitoring data Practice records | Analyse stakeholder requirements Define and agree the service configuration management approach Communicate and integrate the service configuration management approach into the organization’s value streams Review and adjust the service configuration management approach and procedures | Service configuration management approachCMDB Service configuration management communications and knowledge management materials Requests for change and implementation initiatives Service configuration management approach performance reports |
Figure 3.2 shows a workflow diagram of the process.
Table 3.2 provides examples of the process activities.
Table 3.2 Activities of the managing a common approach to the service configuration management process
| Activity | Example |
|---|---|
| Analyse stakeholder requirements | The configuration manager identifies key stakeholders who expect configuration information and requirements. These stakeholders typically include: practice ownersvalue stream ownersproduct ownersservice ownersresource ownersproject managers.The configuration manager documents, prioritizes, and analyses the requirements with the stakeholders. Configuration coordinators, configuration librarians, and external consultants may also be involved.The configuration manager forms a configuration management team from those involved. |
| Define and agree the service configuration management approach | The configuration management team discusses and agrees a service configuration management approach (or plan). The approach typically defines the:service configuration management policies to:assess the relevance of the configuration management information and plan the CMDB scopeoptimize the costs of service configuration informationverify the CMDB dataintegrate the service configuration management activities into the organization’s value streams and practicesreview the approachCI types, taxonomy, and CI modelsnaming and labelling conventionsautomation and integrationCI identification plan: activities, targets, and KPIsroles and responsibilitiesmonitoring and ongoing control proceduresverification proceduresreporting proceduresad-hoc configuration discovery and reportingfunding and cost allocation.The approach is discussed and approved by the key stakeholders, including the sponsors and leaders of the organization. |
| Communicate and integrate the service configuration management approach into the organization’s value streams | The agreed service configuration management approach is communicated to and discussed with stakeholders across the organization. These typically include practitioners who will be participating in the service configuration management activities, technical experts involved in practice automation, and other teams.Stakeholders can decide how formal the training on the service configuration management controls and procedures should be. For the people most involved in the practice, formal initial training and periodic awareness trainings will be necessary.The implementation of the service configuration management approach is performed in conjunction with the IT asset management, supplier management, change enablement, project management, organizational change management, workforce and talent management, relationship management, infrastructure and platform management, and software development and management practices, among others. |
| Review and adjust the service configuration management approach and procedures | The service configuration manager monitors and reviews the adoption, compliance, and effectiveness of the agreed service configuration management approach and procedures. This is done on an event-based (non-standard requests for information, identified gaps in CI data, new requirements) and interval-based basis.Based on the reviews, the approach and/or its practical implementation may be changed. The service configuration management approach performance reports inform the updated approach. |
3.2.2 Capturing, managing, and providing configuration information
This process is focused on updating, maintaining, and providing configuration information. It includes the activities listed in Table 3.3 and transforms the inputs into outputs.
Table 3.3 Inputs, activities, and outputs of the capturing, managing, and providing configuration information process
| Key inputs | Activities | Key outputs |
|---|---|---|
| Service configuration management approach Configuration data Requests for configuration information Service management records | Analyse resources and identify CIs Confirm a CI model Follow the CI model Manage exceptions Review the CI model | Updated CMDB Configuration information for stakeholders Exception reportsCI model review reports |
Figure 3.3 shows a workflow diagram of the process
Table 3.4 provides examples of the process activities.
Table 3.4 Activities of the capturing, managing, and providing configuration information process
| Activity | |
|---|---|
| Analyse resources and identify CIs | Upon discovering a new resource, resource type, or change in the existing CI, the resource owner or configuration librarian identifies the relevant CI model. If in doubt, the resource owner escalates the issue to a configuration manager. |
| Confirm a CI model | The configuration manager reviews the situation, confirms the CI model, or suggests a different one. If needed, the configuration manager may suggest adjustments to the selected CI model. |
| Follow the CI model | The resource owner, configuration manager, and/or configuration librarian follows the selected model. This typically includes:capturing and updating the CI data in the CMDB at each stage of the CI lifecycleensuring the ongoing verification of the CMDB dataproviding up-to-date CI information to relevant stakeholders. |
| Manage exceptions | If an exception occurs during the CI lifecycle, the configuration manager and resource owner handle it in line with organization’s service configuration management approach.Deviations from the agreed procedures should be rare. It is important to ensure ongoing compliance and the maintenance of controls.Exceptions may include non-standard ad-hoc requests for configuration information not included in the CI model. For more, refer to the knowledge management practice guide, section 3.2.2. Exceptions should be documented to be used when reviewing the service configuration management approach, CI models, and procedures. |
| Review the CI model | Upon significant exceptions, or regularly, the configuration manager and the configuration team review the CI models and update them based on collected feedback, reviewed requirements, CI records, verification reports, and new optimization opportunities. |
Verifying configuration data
This process is focused on keeping configuration data complete, correct, and compliant. It includes the activities listed in Table 3.5 and transforms the inputs into outputs.
Table 3.5 Inputs, activities and outputs of the verifying configuration data process
Updated CMDB
Requests for changes
Improvement initiatives
CMDB verification report
| Key inputs | Activities | Key outputs |
|---|---|---|
| Service configuration management approach CMDB Inventory data Exception reports Previous CMDB verification reports | Identify a CI model Verify configuration data Review the verification output Define and implement corrective actions Compose and communicate a CMDB verification report | |
Figure 3.4 shows a workflow diagram of the process.
Table 3.6 provides examples of the process activities.
Activities of the verifying configuration data process
| Activity | Example |
|---|---|
| Identify a CI model | A configuration manager identifies a CI model applicable to the organization’s resource, confirms the verification procedures for the CI, and assigns and communicates responsibilities for verification activities. |
| Verify configuration data | In line with the communicated procedures, teams responsible for the verification procedures collect inventory data. The configuration manager and the CI owner compare inventory data with CMDB data; this comparison should be automated wherever possible. |
| Review the verification output | All cases of CMDB-data incompleteness, incorrectness, or non-compliance, as well as unauthorized changes in resources, must be reviewed by the configuration manager, resource owner, or other people assigned according to the CI model. |
| Define and implement corrective actions | The configuration manager, resource owner, or other people assigned according to the CI model agree, document, and communicate corrective actions to the CMDB and/or organization’s resources. Improvement initiatives to the CI model and/or service configuration management approach may also be suggested. |
| Compose and communicate a CMDB verification report | The configuration manager, resource owner, or other people assigned according to the CI model compose and communicate a CMDB verification report to relevant stakeholders. This report should include proposed corrective actions and improvement initiatives. |
4. Organizations and people
4.1 Roles, competencies, and responsibilities
The practice guides do not describe the practice management roles such as practice owner, practice lead, or practice coach. They focus instead on the specialist roles that are specific to each practice. The structure and naming of each role may differ from organization to organization, so any roles defined in ITIL should not be treated as mandatory, or even recommended. Remember, roles are not job titles. One person can take on multiple roles and one role can be assigned to multiple people.
Roles are described in the context of processes and activities. Each role is characterized with a competency profile based on the model shown in Table 4.1.
Table 4.1 Competency codes and profiles
| Competency code | Competency profile (activities and skills) |
|---|---|
| L | Leader Decision-making, delegating, overseeing other activities, providing incentives and motivation, and evaluating outcomes. |
| А | Administrator Assigning and prioritizing tasks, record-keeping, ongoing reporting, and initiating basic improvements. |
| C | Coordinator/Communicator. Coordinating multiple parties, maintaining communication between stakeholders, and running awareness campaigns. |
| М | Methods and techniques expert. Designing and implementing work techniques, documenting procedures, consulting on processes, work analysis, and continual improvement. |
| Т | Technical expert. Providing technical (IT) expertise and conducting expertise-based assignments |
The key roles responsible for most service configuration activities are resource owners and configuration managers. Examples of other roles which are responsible for service configuration management activities are listed in Table 4.2, together with the associated competency profiles and specific skills.
Table 4.2 Examples of roles with responsibility for service configuration management activities
| Activity | Responsible roles | Competency profile | Specific skills | |
|---|---|---|---|---|
| Managing a common approach to service configuration management | ||||
| Analyse stakeholder requirements | Configuration manager Configuration coordinator Practice owner Product owner Service owner Resource owner Project manager | TC | Good knowledge of the organization, its resources and available information Good understanding of the service configuration management practice and its role in the SVS | |
| Define and agree the service configuration management approach | Configuration management team Consultants | MTC | Good understanding of stakeholder requirements, service configuration management methods and tools, available sources of information, and means of automation | |
| Communicate and integrate the service configuration management approach into the organization’s value streams | Configuration management team | CLTA | Leadership and communication skills Good understanding of the agreed approach Good understanding of stakeholder requirements | |
| Review and adjust the service configuration management approach and procedures | Configuration manager Key stakeholders Configuration management team | MCTA | Good understanding of stakeholder requirements, service configuration management methods and tools, available sources of information, and means of automation | |
| Capturing, managing, and providing configuration information | ||||
| Analyse resources and identify CIs | Configuration manager Configuration coordinator Configuration librarian Resource owner | TA | Good knowledge of the organization’s resources and relevant CI models | |
| Confirm a CI model | Configuration manager Configuration coordinator Configuration librarian Resource owner | MTC | Good knowledge of the organization’s resources and relevant CI models Good knowledge of the organization’s approach to service configuration management | |
| Follow the CI model | Configuration librarian Resource owner | ATC | Good knowledge of the CI model | |
| Manage exceptions | Configuration manager Configuration coordinator Configuration librarian Resource owner | MTCA | Good knowledge of the CI model Good knowledge of the organization’s approach to service configuration management Understanding stakeholder needs | |
| Review the CI model | Configuration manager Resource owner | CMTA | Good knowledge of the CI model Good knowledge of the organization’s approach to service configuration management Understanding stakeholder needs | |
| Verifying configuration data | ||||
| Identify a CI model | Configuration manager Configuration coordinator Configuration librarian Resource owner | TA | Good knowledge of the CI model Good knowledge of the organization’s approach to service configuration management | |
| Verify configuration data | Configuration manager Configuration coordinator Configuration librarian Resource owner | TA | Good knowledge of the CI model Good understanding of configuration data sources and means of automation Knowledge of the relevant organization’s resources | |
| Review the verification output | Configuration manager Configuration coordinator Configuration librarian Resource owner | TA | Good knowledge of the CI model Good knowledge of the organization’s approach to service configuration management Understanding of the configuration data sources and means of automation | |
| Define and implement corrective actions | Configuration manager Configuration coordinator Resource owner | TMCA | Good knowledge of the CI model Good knowledge of the organization’s approach to service configuration management Understanding stakeholder needs | |
| Compose and communicate a CMDB verification report | Configuration manager Configuration coordinator Resource owner | CAT | Good knowledge of the CI model Good knowledge of the organization’s approach to service configuration management Understanding stakeholder needs | |
4.1.1 Configuration manager
The key role of the service configuration management practice is the configuration manager (sometimes called the lead configuration coordinator).
The configuration manager oversees the service configuration management approach and CI models for all CIs that are in scope. In many organizations, the configuration manager role is performed by a dedicated person. In larger organizations operating in many locations or in multiple industries, the configuration manager is supported by a team of configuration coordinators who have very similar responsibilities, but who specialize in a particular territory, industry, or other part of the organization.
This configuration manager role is typically responsible for:
- managing the service configuration management approach
- communicating the service configuration management approach and procedures
- integrating the service configuration management approach into value streams
- deciding whether to include new resources and resource types in the scope
- managing exceptions
- ensuring CI models are followed
- ensuring the CMDB contains valid data
- ensuring the organization complies with practice-related requirements, if applicable
- optimizing and automating the practice
- reporting on the service configuration management performance.
4.1.2 Configuration librarian
Some organizations introduce the role of configuration librarian. This role focuses on manually updating configuration data, verifying the CMDB on an ongoing and periodic basis, and processing ad-hoc requests for configuration information.
This role is important in organizations with a low level of automation and high demand for ad-hoc, non-standard configuration information. It is rarely supported by dedicated resources and may be performed by resource owners.
4.1.3 Resource owner
A resource owner (sometimes called a resource custodian) is a person or team that ensures that a resource or group of resources in the organization are utilized correctly. They ensure that relevant CI models are consistently applied to the resource throughout its lifecycle in the context of the organization’s practices and value streams.
4.2 Organizational structures and teams
Two teams support this practice. Larger organizations have a specialized team of configuration manager(s) and configuration coordinator(s): dedicated specialists focused on the service configuration management practice. This team may be supported by external consultants when specific expertise is needed; typically to review and update the service configuration management approach.
In smaller organizations, the configuration management specialist team is virtual, including people with other roles and tasks to perform. To review and transform the practice, the team may be coordinated as a project; the ongoing activities are embedded in other practices and value streams.
To review and update the service configuration management approach, a wider configuration team is formed to represent multiple stakeholders. This may include:
- configuration managers
- practice owners
- product owners
- service owners
- resource owners
- project managers
- other stakeholders or representatives.
5. Information and technology
5.1 Information exchange
The effectiveness of the service configuration management practice is based on the quality of the information used. This information includes, but is not limited to, information about:
- organizational strategy
- organizational architecture
- the organization’s portfolios
- stakeholder requirements and needs for configuration information
- applicable regulatory requirements
- configuration data from internal and external sources
- technology trends
- CI-related records from management practices
- financial data
- IT asset data.
This information may take various forms, depending on the CI types, organizational requirements, and service configuration management automation. The key inputs and outputs of the practice are listed in section 3.
5.2 Automation and tooling
Ensuring that configuration data is updated at every relevant change of status of the CIs, automating the CMDB, and generally capturing configuration data is very important for the service configuration management practice. Where automation is possible and effective, it may involve the solutions outlined in Table 5.1.
CMS solutions are often a part of integrated service management tools or designed for easy integration with them. They ensure the effective exchange of configuration information between the practices. Typically, key functionalities of CMS solutions include CI discovery, updates, modelling of relationships, impact assessment, data health checks and verification, and wide integration with external data sources.
Table 5.1 Automation solutions for service configuration management activities
| Process activity | Means of automation | >Impact on the effectiveness of the practice | |
|---|---|---|---|
| Managing a common approach to service configuration management | |||
| Analyse stakeholder requirements | Analysis and communication tools | Collection and analysis of requirements, discussions, and prioritization | Medium |
| Define and agree the service configuration management approach | Analysis and communication toolsCMS tools | Discussions, prioritization, data and workflow modelling, integration, and data exchange | High |
| Communicate and integrate the service configuration management approach into the organization’s value streams | CMS toolsDiscovery and monitoring tools Service management record-keeping tools | Integration with other practices for data exchange | High |
| Review and adjust the service configuration management approach and procedures | Analysis and communication toolsCMS tools | Discussions, prioritization, data and workflow modelling, integration, and data exchange | High |
| Capturing, managing, and providing configuration information | |||
| Analyse resources and identify CIs | CMS toolsDiscovery and monitoring tools Service management record-keeping tools | Integration with other practices for data exchangeCMDB navigation CI models library | High |
| Confirm a CI model | CMS toolsDiscovery and monitoring tools Service management record-keeping tools | Integration with other practices for data exchangeCMDB navigation CI models library | High |
| Follow the CI model | CMS toolsDiscovery and monitoring tools Service management record-keeping tools | Integration with other practices for data exchangeCMDB navigation CI models library | High |
| Manage exceptions | CMS toolsDiscovery and monitoring tools Service management record-keeping tools | Integration with other practices for data exchangeCMDB navigation CI models library | High |
| Review the CI model | CMS toolsDiscovery and monitoring tools Service management record-keeping tools | Integration with other practices for data exchangeCMDB navigation CI models library | High |
| Verifying configuration data | |||
| Identify a CI model | CMS toolsDiscovery and monitoring tools Service management record-keeping tools | Integration with other practices for data exchangeCMDB navigation CI models library | |
| CMS tools Discovery and monitoring tools Service management record-keeping tools | Integration with other practices for data exchangeCMDB navigation and audit Data health monitoring and verificationCI models library | High | |
| Review the verification output | CMS tools Service management record-keeping tools | Integration with other practices for data exchange CMDB navigation and audit Data health monitoring and verification | High |
| Define and implement corrective actions | CMS tools Service management record-keeping tools | Integration with other practices for data exchangeCMDB navigation and audit Configuration baselines libraryCI models library | High |
| Compose and communicate a CMDB verification report | CMS tools Service management record-keeping tools Communication tools | Communication, discussions Record-keeping | Medium |
6. Partners and suppliers
Very few services are delivered using only an organization’s own resources. Most, if not all, depend on other services, often provided by third parties outside the organization (see section 2.4 of ITIL Foundation: ITIL 4 Edition for a model of a service relationship). This means that organizations constantly handle resources that are provided as part of third-party services. Similarly, organizations’ resources are widely used by their service consumers. This requires the effective coordination of the service configuration management practice between the members of the service relationship ecosystem. The exact level of coordination depends on the type of service relationship. The closer the relationship and higher the trust, the more configuration information can be shared and management activities performed together. At minimum, an exchange of limited configuration data between the organizations is established: at maximum, a wide integration or sharing of CMSs can be considered.
Partners and suppliers integrated into an organization usually have access to the organization’s CMS so that they can effectively fulfil their roles.
7. Important reminder
Most of the content of the practice guides should be taken as a suggestion of areas that an organization might consider when establishing and nurturing their own practices. The practice guides are catalogues of things that organizations might think about, not a list of answers. When using the content of the practice guides, organizations should always follow the ITIL guiding principles:
- focus on value
- start where you are
- progress iteratively with feedback
- collaborate and promote visibility
- think and work holistically
- keep it simple and practical
- optimize and automate.
More information on the guiding principles and their application can be found in section 4.3 of ITIL®
Foundation: ITIL 4 Edition.