Harness Configuration Management Superpowers

Create a configuration management practice that will provide ongoing value to the organization.

EXECUTIVE BRIEF

Analyst Perspective

A robust configuration management database (CMDB) can provide value to the business and superpowers to IT. It's time to invest smartly to reap the rewards.

IT environments are becoming more and more complex, and balancing demands for stability and demands for faster change requires visibility to make the right decisions. IT needs to know their environment intimately. They need to understand dependencies and integrations and feel confident they are making decisions with the most current and accurate view.

Solutions for managing operations rely on the CMDB to bring visibility to issues, calculate impact, and use predictive analytics to fix performance issues before they become major incidents. AIOps solutions need accurate data, but they can also help identify configuration drift and flag changes or anomalies that need investigation.

The days of relying entirely on manual entry and updates are all but gone, as the functionality of a robust configuration management system requires daily updates to provide value. We used to rely on that one hero to make sure information was up to date, but with the volume of changes we see in most environments today, it's time to improve the process and provide superpowers to the entire IT department.

Sandi Conrad, ITIL Managing Professional
Principal Research Director, IT Infrastructure & Operations, Info-Tech Research Group

Executive Summary

Your Challenge

• Build a configuration management database (CMDB): You need to implement a CMDB, populate it with records and relationships, and integrate it with discovery and management tools.
• Identify the benefits of a CMDB: Too many CMDB projects fail because IT tries to collect everything. Base your data model on the desired use cases.
• Define roles and responsibilities: Keeping data accurate and updated is difficult. Identify who will be responsible for helping

Common Obstacles

• Significant process maturity is required: Service configuration management (SCM) requires high maturity in change management, IT asset management, and service catalog practices.
• Large investment: Building a CMDB takes a large amount of effort, process, and expertise.
• Tough business case: Configuration management doesn't directly provide value to the business, but it requires a lot of investment from IT.

Info-Tech's Approach

• Define your scope and objectives: Identify the use cases for SCM and prioritize those objectives into phases.
• Design the CMDB data model: Align with your existing configuration management system's data model.
• Operationalize configuration record updates: Integrate your SCM practice with existing practices and lifecycles.

Start small

Scope creep is a serial killer of configuration management databases and service configuration management practices.

Insight summary

Many vendors are taking a CMDB-first approach to enable IT operations or sometimes asset management. It's important to ensure processes are in place immediately to ensure the data doesn't go stale as additional modules and features are activated.

Define processes early to ensure success

The right mindset is just as important as the right tools. By involving everyone early, you can ensure the right data is captured and validated and you can make maintenance part of the culture. This is critical to reaching early and continual value with a CMDB.

Identify use cases

The initial use case will be the driving force behind the first assessment of return on investment (ROI). If ROI can be realized early, momentum will increase, and the team can build on the initial successes.

If you don't see value in the first year, momentum diminishes and it's possible the project will never see value.

Keep the initial scope small and focused

Discovery can collect a lot of data quickly, and it's possible to be completely overwhelmed early in the process.

Build expertise and troubleshoot issues with a smaller scope, then build out the process.

Minimize customizations

Most CMDBs have classes and attributes defined as defaults. Use of the defaults will enable easier implementation and faster time to value, especially where automations and integrations depend on standard terms for field mapping.

Automate as much as possible

In large, complex environments, the data can quickly become unmanageable. Use automation as much as possible for discovery, dependency mapping, validation, and alerts. Minimize the amount of manual work but ensure everyone is aware of where and how these manual updates need to happen to see continual value.

Configuration management will improve functionality of all surrounding processes

A well-functioning CMDB empowers almost all other IT management and governance practices.

Service configuration management is about:

• Building a system of record about IT services and the components that support those services.
• Continuously reconciling and validating information to ensure data accuracy.
• Ensuring the data lifecycle is defined and well understood and can pass data and process audits.
• Accessing information in a variety of ways to effectively serve IT and the business.

Configuration management most closely impacts these practices

Info-Tech Research Group sees a clear relationship.

When an IT department reports they are highly effective at configuration management, they are much more likely to report they are highly effective at these management and governance processes:

The data is clear

Service configuration management is about more than just doing change management more effectively.

Source: Info-Tech Research Group, IT Management and Governance Diagnostic; N=684 organizations, 2019 to July 2022.

Make the case to use configuration management to improve IT operations

Consider the impact of access to data for informing innovations, optimization efforts, and risk assessments.

75% of Uptime's 2021 survey respondents who had an outage in the past three years said the outage would have been prevented if they'd had better management or processes.(1)

It doesn't have to be that way!

Enterprise-grade IT service management (ITSM) tools require a CMDB for the different modules to work together and to enable IT operations management (ITOM), providing greater visibility.

Decisions about changes can be made with accurate data, not guesses.

The CMDB can give the service desk fast access to helpful information about the impacted components, including a history of similar incidents and resolutions and the relationship between the impacted components and other systems and components.

Turn your team into IT superheroes.

CMDB data makes it easier for IT Ops groups to:

• Avoid change collisions.
• Eliminate poor changes due to lack of visibility into complex systems.
• Identify problematic equipment.
• Troubleshoot incidents.
• Expand the services provided by tier 1 and through automation.

Benefits of configuration management

For IT

• Configuration management will supercharge processes that have relied on inherent knowledge of the IT environment to make decisions.
• IT will more quickly analyze and understand issues and will be positioned to improve and automate issue identification and resolution.
• Increase confidence and reduce risks for decisions involving release and change management with access to accurate data, regardless of the complexity of the environment.
• Reduce or eliminate unplanned work related to poor outcomes due to decisions made with incorrect or incomplete data.

For the Business

• Improve strategic planning for business initiatives involving IT solutions, which may include integrations, development, or security concerns.
• More quickly deploy new solutions or updates due to visibility into complex environments.
• Enable business outcomes with reliable and stable IT systems.
• Reduce disruptions caused by planning without accurate data and improve resolution times for service interruptions.
• Improve access to reporting for budgeting, showbacks, and chargebacks as well as performance metrics.

Measure the value of this blueprint

Fast-track your planning and increase the success of a configuration management program with this blueprint

"The workshop was well run, with good facilitation, and gained participation from even the most difficult parts of the audience. The best part of the experience was that if I were to find myself in the same position in the future, I would repeat the workshop."

– University of Exeter

Info-Tech offers various levels of support to best suit your needs

DIY Toolkit

“Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful.”

Guided Implementation

“Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track.”

Workshop

“We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place.”

Consulting

“Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project.”

Diagnostics and consistent frameworks used throughout all four options

Guided Implementation

What does a typical GI on this topic look like?

A Guided Implementation (GI) is a series of calls with an Info-Tech analyst to help implement our best practices in your organization.

A typical GI is between 8 to 12 calls over the course of 4 to 9 months.

Workshop Overview

Contact your account representative for more information.
workshops@infotech.com 1-888-670-8889

Blueprint deliverables

Each step of this blueprint is accompanied by supporting deliverables to help you accomplish your goals:

Configuration Management Project Charter

Detail your approach to building an SCM practice and a CMDB.

Use Cases and Data Worksheet

Capture the action items related to your SCM implementation project.

Configuration Manager Job Description

Use our template for a job posting or internal job description.

Configuration Management Diagram Template Library

Use these diagrams to simplify building your SOP.

Configuration Management Policy

Set expectations for configuration control.

Configuration Management Audit and Validation Checklist

Use this framework to validate controls.

Configuration Control Board Charter

Define the board's responsibilities and meeting protocols.

Key deliverable:

Configuration Management Standard Operating Procedures Template

Outlines SCM roles and responsibilities, the CMDB data model, when records are expected to change, and configuration baselines.

Phase 1

Configuration Management Strategy

This phase will walk you through the following aspects of a configuration management system:

• Scope
• Use Cases
• Reports and Analytics

This phase involves the following participants:

• IT and business service owners
• Business/customer relationship managers
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• SCM project manager
• SCM project sponsor

Harness Service Configuration Management Superpowers

Establish clear definitions

Ensure everyone is using the same terms.

What is a configuration management database (CMDB)?

The CMDB is a system of record of your services and includes a record for everything you need to track to effectively manage your IT services.

Anything that is tracked in your CMDB is called a configuration item (CI). Examples of CIs include:

• User-Facing Services
• IT-Facing Services
• Business Capabilities
• Relationships
• IT Infrastructure Components
• Enterprise Software
• End-User Devices
• Documents

Other systems of record can refer to CIs, such as:

• Ticket database: Tickets can refer to which CI is impacted by an incident or provided as part of a service request.
• Asset management database (AMDB): An IT asset is often also a CI. By associating asset records with CI records, you can leverage your IT asset data in your reporting.
• Financial systems: If done well, the CMDB can supercharge your IT financial cost model.

CMDBs can allow you to:

• Query multiple databases simultaneously (so long as you have the CI name field in each database).
• Build automated workflows and chatbots that interact with data across multiple databases.
• More effectively identify the potential impact of changes and releases.

Do not confuse asset with configuration

Asset and configuration management look at the same world through different lenses

• IT asset management (ITAM) tends to focus on each IT asset in its own right: assignment or ownership, lifecycle, and related financial obligations and entitlements.
• Configuration management is focused on configuration items (CIs) that must be managed to deliver a service and the relationships and integrations with other CIs.
• ITAM and configuration management teams and practices should work closely together. Though asset and configuration management focus on different outcomes, they may use overlapping tools and data sets. Each practice, when working effectively, can strengthen the other.
• Many objects will exist in both the CMDB and AMDB, and the data on those shared objects will need to be kept in sync.

*Discovery, dependency mapping, and data normalization are often features or modules of configuration management, asset management, or IT service management tools.

Start with ITIL 4 guiding principles to make your configuration management project valuable and realistic

Focus on where CMDB data will provide value and ensure the cost of bringing that data in will be reasonable for its purpose. Your end goal should be not just to build a CMDB but to use a CMDB to manage workload and workflows and manage services appropriately.

ITIL 4 guiding principles as described by AXELOS

Step 1.1

Identify use cases and desired benefits for service configuration management

Activities

1.1.1 Brainstorm data collection challenges

1.1.2 Define goals and how you plan to meet them

1.1.3 Brainstorm and prioritize use cases

1.1.4 Identify the data needed to reach your goals

1.1.5 Record required data sources

This step will walk you through the following aspects of a configuration management system:

• Scope
• Use cases

This phase involves the following participants:

• IT and business service owners
• Business/customer relationship managers
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• Project sponsor
• Project manager

Identify potential obstacles in your organization to building and maintaining a CMDB

Often, we see multiple unsuccessful attempts to build out a CMDB, with teams eventually losing faith and going back to spreadsheets. These are common obstacles:

• Significant manual data collection, which is rarely current and fully accurate.
• Multiple discovery solutions creating duplicate records, with no clear path to deduplicate records.
• Manual dependency mapping that isn't accurate because it's not regularly assessed and updated.
• Hybrid cloud and on-premises environment with discovery solutions only partially collecting as the right discovery and dependency mapping solutions aren't in place.
• Dynamic environments (virtual, cloud, or containers) that may exist for a very short time, but no one knows how they should be managed.
• Lack of expertise to maintain and update the CMDB or lack of an assigned owner for the CMDB. If no one owns the process and is assigned as a steward of data, it will not be maintained.
• Database that was designed with other purposes in mind and is heavily customized, making it difficult to use and maintain.

Understanding the challenges to accessing and maintaining quality data will help define the risks created through lack of quality data.

This knowledge can drive buy-in to create a configuration management practice that benefits the organization.

1.1.1 Brainstorm data collection challenges

Involve stakeholders.
Allot 45 minutes for this discussion.

1. As a group, brainstorm the challenges you have with data:
2. Accuracy and trustworthiness: What challenges do you have with getting accurate data on IT services and systems?
   1. Access: Where do you have challenges with getting data to people when they need it?
   2. Manually created data: Where are you relying on data that could be automatically collected?
   3. Data integration: Where do you have issues with integrating data from multiple sources?
   4. Impact: What is the result of these challenges?
3. Group together these challenges into similar issues and identify what goals would help overcome them.
4. Record these challenges in the Configuration Management Project Charter, section 1.2: Project Purpose.

Download the Configuration Management Project Charter

Info-Tech Maturity Ladder

Identify your current and target state

INNOVATOR

• Characteristics of business partner
• Integration with orchestration tools

BUSINESS PARTNER

Data collection and validation is fully automated

Integrated with several IT processes

Meets the needs of IT and business use cases

TRUSTED OPERATOR

• Data collection and validation is partially or fully automated
• Trust in data accuracy is high, meets the needs of several IT use cases

FIREFIGHTER

• Data collection is partially or fully automated, validation is ad hoc
• Trust in data accuracy is variable, used for decision making

UNSTABLE

• Ad hoc or manual data collection and verification process
• Trust in data accuracy is low, and data is not easily or commonly used
• A more detailed assessment can be completed using Info-Tech's Configuration Management Audit and Validation Checklist.

INNOVATOR Characteristics of business partner Integration with orchestration tools BUSINESS PARTNER Data collection and validation is fully automated Integrated with several IT processes Meets the needs of IT and business use cases TRUSTED OPERATOR Data collection and validation is partially or fully automated Trust in data accuracy is high, meets the needs of several IT use cases FIREFIGHTER Data collection is partially or fully automated, validation is ad hoc Trust in data accuracy is variable, used for decision making UNSTABLE Ad hoc or manual data collection and verification process Trust in data accuracy is low, and data is not easily or commonly used A more detailed assessment can be completed using Info-Tech's Configuration Management Audit and Validation Checklist.

Define goals for your CMDB to ensure alignment with all stakeholders

• How are business or IT goals being hindered by not having the right data available?
• If the business isn't currently asking for service-based reporting and accountability, start with IT goals. This will help to develop goals that will be most closely aligned to the IT teams' needs and may help incentivize the right behavior in data maintenance.
• Configuration management succeeds by enabling its stakeholders to achieve their outcomes. Set goals for configuration management based on the most important outcomes expected from this project. Ask your stakeholders:
  1. What are the business' or IT's planned transformational initiatives?
  2. What are your highest priority goals?
  3. What should the priorities of the configuration management practice be?
• The answers to these questions will shape your approach to configuration management. Direct input from your leadership and executives, or their delegates, will help ensure you're setting a solid foundation for your practice.
• Identify which obstacles will need to be overcome to meet these goals.

"[T]he CMDB System should be viewed as a 'system of relevance,' rather than a 'single source of truth.' The burdens of relevance are at once less onerous and far more meaningful in terms of action, analysis, and automation. While 'truth' implies something everlasting or at least stable, relevance suggests a far more dynamic universe."

– CMDB Systems, Making Change Work in the Age of Cloud and Agile, Drogseth et al

Identify stakeholders to discuss what they need from a CMDB; business and IT needs will likely differ

Define your audience to determine who the CMDB will serve and invite them to these conversations. The CMDB can aid the business and IT and can be structured to provide dashboards and reports for both.

Nondiscoverable configuration items will need to be created for both audiences to organize CIs in a way that makes sense for all uses.

Integrations with other systems may be required to meet the needs of your audience. Note integrations for future planning.

1.1.2 Define goals and how you plan to meet them

Involve stakeholders.

Allot 45 minutes for this discussion.

As a group, identify current goals for building and using a CMDB.

Why are we doing this?

• How do you hope to use the data within the CMDB?
• What processes will be improved through use of this data and what are the expected outcomes?

How will we improve the process?

• What processes will be put in place to ensure data integrity?
• What tools will be put in place to improve the methods used to collect and maintain data?

Record these goals in the Configuration Management Project Charter, section 1.3: Project Objectives.

It's easy to think that if you build it, they will come, but CMDBs rarely succeed without solid use cases

Set expectations for your organization that defined and fulfilled use cases will factor into prioritization exercises, functional plans, and project milestones to achieve ROI for your efforts.

A good use case:

• Justifies resource allocation
• Gains funding for the right tools
• Builds stakeholder support
• Drives interest and excitement
• Gains support from anyone in a position to help build out and validate the data
• Helps to define success

In the book CMDB Systems, Making Change Work in the Age of Cloud and Agile, authors Drogseth, Sturm, and Twing describe the secrets of success:

A documented evaluation of CMDB System vendors showed that while most "best case" ROI fell between 6 and 9 months for CMDB deployments, one instance delivered ROI for a significant CMDB investment in as little as 2 weeks!

If there's a simple formula for quick time to value for a CMDB System, it's the following:

Mature levels of process awareness
+ Strong executive level support
+ A ready and willing team with strongly supportive stakeholders
+ Clearly defined and ready phase one use case
+ Carefully selected, appropriate technologies

All this = Powerful early-phase CMDB System results

Define and prioritize use cases for how the CMDB will be used to drive value

The CMDB can support several use cases and may require integration with various modules within the ITSM solution and integration with other systems.

Document the use cases that will drive your CMDB to relevance, including the expected benefits for each use case.

Identify the dependencies that will need to be implemented to be successful.

Define "done" so that once data is entered, verified, and mapped, these use cases can be realized.

"Our consulting experience suggests that more than 75% of all strategic initiatives (CMDB or not) fail to meet at least initial expectations across IT organizations. This is often due more to inflated expectations than categorical failure."

– CMDB Systems, Making Change Work in the Age of Cloud and Agile, Drogseth et al.

After identifying use cases, determine the scope of configuration items required to feed the use cases

On-premises software and equipment will be critical to many use cases as the IT team and partners work on network and data-center equipment, enterprise software, and integrations through various means, including APIs and middleware. Real-time and near real-time data collection and validation will ensure IT can act with confidence.

Cloud use can include software as a service (SaaS) solutions as well as infrastructure and platform as a service (IaaS and PaaS), and this may be more challenging for data collection. Tools must be capable of connecting to cloud environments and feeding the information back into the CMDB. Where on-premises and cloud applications show dependencies, you might need to validate data if multiple discovery and dependency mapping solutions are used to get a complete picture. Tagging will be crucial to making sense of the data as it comes into the CMDB.

In-house developed software would be beneficial to have in the CMDB but may require more manual work to identify and classify once discovered. A combination of discovery and tagging may be beneficial to input and classification.

Highly dynamic environments may require data collection through integration with a variety of solutions to manage and record continuous deployment models and verifications, or they may rely on tags and activity logs to record historical activity. Work with a partner who specializes in CI/CD to help architect this use case.

Containers will require an assessment of the level of detail required. Determine if the container is a CI and if the content will be described as attributes. If there is value to your use case to map the contents of each container as separate CIs within the container CI, then you can map to that level of detail, but don't map to that depth unless the use case calls for it.

Internet of Things (IoT) devices and applications will need to match a use case as well. IoT device asset data will be useful to track within an asset database but may have limited value to add to a CMDB. If there are connections between IoT applications and data warehouses, the dependencies should likely be mapped to ensure continued dataflow.

Out of scope

A single source of data is highly beneficial, but don't make it a catchall for items that are not easily stored in a CMDB.

Source code should be stored in a definitive media library (DML). Code can be linked to the CMDB but is generally too big to store in a CMDB and will reduce performance for data retrieval.

Knowledge articles and maintenance checklists are better suited to a knowledge base. They can also be linked to the CDMB if needed but this can get messy where many-to-many relationships between articles and CIs exist.

Fleet (transportation) assets and fixed assets should be in fleet management systems and accounting systems, respectively. Storing these types of data in the CMDB doesn't provide value to the support process.

1.1.3 Brainstorm and prioritize use cases

Which IT practices will you supercharge?

Focus on improving both operations and strategy.

1. Brainstorm the list of relevant use cases. What do you want to do with the data from the CMDB? Consider:
   1. ITSM management and governance practices
   2. IT operations, vendor orchestration, and service integration and management (SIAM) to improve vendor interactions
   3. IT finance and business service reporting needs
2. Identify which use cases are part of your two- to three-year plan, including the purpose for adding configuration data into that process. Prioritize one or two of these use cases to accomplish in your first year.
3. Identify dependencies to manage as part of the solution and define a realistic timeline for implementing integrations, modules, or data sources.
4. Document this table in the Configuration Management Project Charter, section 2.2: Use Cases.

Determine what additional data will be needed to achieve your use cases

Regardless of which use cases you are planning to fulfill with the CMDB, it is critical to not add data and complexity with the plan of resolving every possible inquiry. Ensure the cost and effort of bringing in the data and maintaining it is justified. The complexity of the environment will impact the complexity of data sources and integrations for discovery and dependency mapping.

Before bringing in new data, consider:

• Is this information available in other maintained databases now?
• Will this data be critical for decision making? If it is nice to have or optional, can it be automatically moved into the database and maintained using existing integrations?
• Is there a cost to bringing the data into the CMDB and maintaining it? Is that cost reasonable for its purpose?
• How frequently will this information be accessed, and can it be updated in an adequate cadence to meet these needs?
• When does this information need to be available?

Info-Tech Insight

If data will be used only occasionally upon request, determine if it will be more efficient to maintain it or to retrieve it from the CMDB or another data source as needed.

Remember, within the data sets, service configuration models can be used for:

• Impact analysis
• Cause and effect analysis
• Risk analysis
• Cost allocation
• Availability analysis and planning

1.1.4 Expand your use cases by identifying the data needed to reach your goals

Involve stakeholders.

Allot 60 minutes for this discussion.

Review use cases and their goals.

Identify what data will be required to meet those goals and determine whether it will be mandatory or optional/nice-to-have information.

Identify sources of data for each type of data. Color code or sort.

Italicize data points that can be automatically discovered.

Gain consensus on what information will be manually entered.

Record the data in the Use Cases and Data Worksheet.

Download the Use Cases and Data Worksheet

Use discovery and dependency mapping tools to automatically update the CMDB

Avoid manual data entry whenever possible.

Consider these features when looking at tools:

• Application dependency mapping: Establishing and tracking the relationships and dependencies between system components, applications, and IT services. The ideal tool will be able to generate maps automatically.
• Agentless and agent discovery: Scanning systems with both agent and agentless approaches. Agent-based scanning provides comprehensive information on applications used in individual endpoints, which is helpful in minimizing its IT footprint. However, agents require endpoint access. Agentless-based scanning provides a broader and holistic view of deployed applications without the need to install an agent on end devices, which can be good enough for inventory awareness.
• Data export capability: Easy exporting of application inventory information to be used in reports and other tools.
• Dashboards and chart visualization: Detailed list of the application inventory, including version number, number of users, licenses, deployment location, and other application details. These details will inform decision makers of each application's health and its candidacy for further rationalization activities.
• Customizable scanning scripts: Tailor your application discovery approach by modifying the scripts used to scan your systems.
• Integration with third-party tools: Easy integration with other systems with out-of-the-box plugins or customizable APIs.

Determine which data collection methods will be used to populate the CMDB

The effort-to-value ratio is an important factor in populating a CMDB. Manual efforts require a higher process focus, more intensive data validation, and a constant need to remind team members to act on every change.

• Determine what amount of effort is appropriate for each data grouping and use case. As decisions are made to expand data within the CMDB, the effort-to-value ratio should always factor in. To be usable, data must be accurate, and every piece of data that needs to be manually entered runs the risk of becoming obsolete.
• Identify which data sources will bring in each type of data. Where there is a possibility of duplicate records being created, one of the data sources will need to be identified as the primary.
• If the decision is to manually enter configuration items early in the process, be aware that automation may create duplicates of the CIs that will need to be deduplicated at some point in the process to make the information more usable.
• Typically, items are discovered, validated, then mapped, but there will be variations depending on the source.
• Active Directory or LDAP may be used to bring users and technicians into the CMDB. Data may be imported from spreadsheets. Identify efforts where data cleanup may have to happen before transferring into the CMDB.
• Identify how often manual imports will need to be conducted to make sure data is usable.

Identify other nondiscoverable data that will need to be added to or accessed by the CMDB

Foundational data, such as technicians, end users and approvers, roles, location, company, agency, department, building, or cost center, may be added to tables that are within or accessed by the CMDB. Work with your vendor to understand structure and where this information resides.

• These records can be imported from CSV files manually, but this will require manual removal or edits as information changes.
• Integration with the HRIS, Active Directory, or LDAP will enable automatic updates through synchronization or scheduled imports.
• If synchronization is fully enabled, new data can be added and removed from the CMDB automatically.
• Identify which nondiscoverable attributes will be needed, such as system criticality, support groups, groups it is managed by, location.
• If partially automating the process, identify where manual updates will need to occur.
• If fully automating the process, notifications will need to be set up when business owner or product or technical owner fields become empty to prompt defining a replacement within the CMDB.
• Determine who will manage these updates.
• Work with your CMDB implementation vendor to determine the best option for bringing this information in.

1.1.5 Record required data sources

Allot 15 minutes for this discussion.

1. Where do you track the work involved in providing services? Typically, your ticket database tracks service requests and incidents. Additional data sources can include:
   • Enterprise resource planning tools for tracking purchase orders
   • Project management information system for tracking tasks
2. What trusted data sources exist for the technology that supports these services? Examples include:
   • Management tools (e.g. Microsoft Endpoint Configuration Manager)
   • Architectural diagrams and network topology diagrams
   • IT asset management database
   • Spreadsheets
   • Other systems of record
3. What other data sources can help you gather the data you identified in activity 1.1.4?
4. Record the relevant data sources for each use case in the Configuration Management Standard Operating Procedures, section 6: Data Collection and Updates.

Info-Tech Insight

Improve the trustworthiness of your CMDB as a system of record by relying on data that is already trusted.

Step 1.2

Define roles and responsibilities

Activities

1.2.1 Record the project team and stakeholders

1.2.2 Complete a RACI chart to define who will be accountable and responsible for configuration tasks

This step will walk you through the following aspects of a configuration management system:

• Roles and responsibilities

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• Project manager

Identify the roles you need in your SCM project

Determine which roles will need to be involved in the initial project and how to source these roles.

Leadership Roles
Oversee the SCM implementation

1. Configuration Manager – The practice owner for SCM. This is a long-term role.
2. Configuration Control Board (CCB) Chair – An optional role that oversees proposed alterations to configuration plans. If a CCB is implemented, this is a long-term role.
3. Project Sponsor or Program Sponsor – Provides the necessary resources for building the CMDB and SCM practices.
4. Architecture Roles
   Plan the program to build strong foundation
   1. Configuration Management Architect – Technical leader who defines the overall CM solution, plans the scope, selects a tool, and leads the technical team that will implement the solution.
   2. Requirements Analyst – Gathers and manages the requirements for CM.
   3. Process Engineer – Defines, documents, and implements the entire process.

Architecture Roles
Plan the program to build strong foundation

1. Configuration Management Architect – Technical leader who defines the overall CM solution, plans the scope, selects a tool, and leads the technical team that will implement the solution.
2. Requirements Analyst – Gathers and manages the requirements for CM.
3. Process Engineer – Defines, documents, and implements the entire process.

Engineer Roles
Implement the system

1. Logical Database Analyst (DBA) – Designs the structure to hold the configuration management data and oversees implementation.
2. Communications and Trainer – Communicates the goals and functions of CM and teaches impacted users the how and why of the process and tools.

Administrative Roles
Permanent roles involving long-term ownership

1. Technical Owner – The system administrator responsible for their system's uptime. These roles usually own the data quality for their system.
2. Configuration Management Integrator – Oversees regular transfer of data into the CMDB.
3. Configuration Management Tool Support – Selects, installs, and maintains the CM tool.
4. Impact Manager – Analyzes configuration data to ensure relationships between CIs are accurate; conducts impact analysis.

1.2.1 Record the project team and stakeholders

Allocate 25 minutes to this discussion.

1. Record the project team.

1. Identify the project manager who will lead this project.
2. Identify key personnel that will need to be involved in design of the configuration management system and processes.
3. Identify where vendors/outsourcers may be required to assist with technical aspects.
4. Document the project team in the Configuration Management Project Charter, section 1.1: Project Team.

2. Record a list of stakeholders.

1. Identify stakeholders internal and external to IT.
2. Build the stakeholder profile. For each stakeholder, identify their role, interest in the project, and influence on project success. You can score these criteria high/medium/low or score them out of ten.
3. If managed service providers will need to be part of the equation, determine who will be the liaison and how they will provide or access data.

Even with full automation, this cannot be a "set it and forget it" project if it is to be successful long-term

Create a team to manage the process and data updates and to ensure data is always usable.

• Services may be added and removed.
• Technology will change as technical debt is reduced.
• Vendors may change as contract needs develop.
• Additional use cases may be introduced by IT and the business as approaches to management evolve.
• AIOps can reduce the level of effort and improve visibility as configuration items change from the baseline and notifications are automated.
• Changes can be checked against requests for changes through automated reconciliations, but changes will still need to be investigated where they do not meet expectations.
• Manual data changes will need to be made regularly and verified.

"We found that everyone wanted information from the CMDB, but no one wanted to pay to maintain it. People pointed to the configuration management team and said, 'It's their responsibility.'

Configuration managers, however, cannot own the data because they have no way of knowing if the data is accurate. They can own the processes related to checking accuracy, but not the data itself."
– Tim Mason, founding director at TRM Associates
(Excerpt from Viewpoint: Focus on CMDB Leadership)

Include these roles in your CMDB practice to ensure continued success and continual improvement

These roles can make up the configuration control board (CCB) to make decisions on major changes to services, data models, processes, or policies. A CCB will be necessary in complex environments.

Configuration Manager

This role is focused on ensuring everyone works together to build the CMDB and keep it up to date. The configuration manager is responsible to:

• Plan and manage the standards, processes, and procedures and communicate all updates to appropriate staff. Focused on continual improvement.
• Plan and manage population of the CMDB and ensure data included meets criteria for cost effectiveness and reasonable effort for the value it brings.
• Validate scope of services and CIs to be included and controlled within the CMDB and manage exceptions.
• Audit data quality to ensure it is valid, is current, and meets defined standards.
• Evaluate and recommend tools to support processes, data collection, and integrations.
• Ensure configuration management processes interface with all other service and business management functions to meet use cases.
• Report on configuration management performance and take appropriate action on process adherence and quality issues.

Configuration Librarian

This role is most important where manual data entry is prevalent and where many nonstandard configurations are in place. The librarian role is often held by the tool administrator. The librarian focuses specifically on data within the CMDB, including:

• Manual updates to configuration data.
• CMDB data verification on a regular schedule.
• Processing ad hoc requests for data.

Product/Service/Technical Owners

The product or technical owner will validate information is correctly updating and reflects the existing data requirements as new systems are provisioned or as existing systems change.

Interfacing Practice Owners

All practice owners, such as change manager, incident manager, or problem manager, must work with the configuration team to ensure data is usable for each of the use cases they are responsible for.

Download the Configuration Manager job description

Assign configuration management responsibilities and accountabilities

Align authority and accountability.

• A RACI exercise will help you discuss and document accountability and responsibility for critical configuration management activities.
• When responsibility and accountability are not well documented, it's often useful to invite a representative of the roles identified to participate in this alignment exercise. The discussion can uncover contrasting views on responsibility and governance, which can help you build a stronger management and governance model.
• The RACI chart can help you identify who should be involved when making changes to a given activity. Clarify the variety of responsibilities assigned to each key role.
• In the future, you may need to define roles in more detail as you change your configuration management procedures.

Responsible: The person who actually gets the job done.
Different roles may be responsible for different aspects of the activity relevant to their role.

Accountable: The one role accountable for the activity (in terms of completion, quality, cost, etc.)
Must have sufficient authority to be held accountable; responsible roles are often accountable to this role.

Consulted: Those who need the opportunity to provide meaningful input at certain points in the activity; typically, subject matter experts or stakeholders. The more people you must consult, the more overhead and time you'll add to a process.

Informed: Those who receive information regarding the task but do not need to provide feedback.
Information might relate to process execution, changes, or quality.

Complete a RACI chart to define who will be accountable and responsible for configuration tasks

Determine what roles will be in place in your organization and who will fulfill them, and create your RACI chart to reflect what makes sense for your organization. Additional roles may be involved where there is complexity.

1.2.2 Complete a RACI chart to define who will be accountable and responsible for configuration tasks

Allot 60 minutes for this discussion.

1. Open the Configuration Management Standard Operating Procedures, section 4.1: Responsibility Matrix. In the RACI chart, review the top row of roles. Smaller organizations may not need a configuration control board, in which case the configuration manager may have more authority.
2. Modify or expand the process tasks in the left column as needed.
3. For each role, identify what that person is responsible for, accountable for, consulted on, or informed of. Fill out each column.
4. Document in the SOP. Schedule a time to share the results with organization leads.
5. Distribute the chart among all teams in your organization.
6. Describe additional roles as needed in the documentation.
7. Add accountabilities and responsibilities for the CCB into the Configuration Control Board Charter.
8. If appropriate, add auxiliary roles to the Configuration Management Standard Operating Procedures, section 4.2: Configuration Management Auxiliary Role Definitions.

Notes:

1. Assign one Accountable for each task.
2. Have one or more Responsible for each task.
3. Avoid generic responsibilities such as "team meetings."
4. Keep your RACI definitions in your documents for quick reference.

Refer back to the RACI chart when building out the communications plan to ensure accountable and responsible team members are on board and consulted and informed people are aware of all changes.

Phase 2

Configuration Management Data Model

This phase will walk you through the following aspects of a configuration management system:

• Data Model
• Customer-Facing and Supporting Services
• Business Capabilities
• Relationships
• IT Infrastructure Components
• Enterprise Software
• End-User Devices
• Documents

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• CM practice manager
• CM project manager

Step 2.1

Build a framework for CIs and relationships

Activities

Document services:

2.1.1 Define and prioritize your services

2.1.2 Test configuration items against existing categories

2.1.3 Create a configuration control board charter to define the board's responsibilities and protocols

This step will walk you through the following aspects of a configuration management system:

• Data model
• Configuration items
• Relationships

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• CM practice manager
• Project manager

Making sense of data daily will be key to maintaining it, starting with services

As CIs are discovered and mapped, they will automatically map to each other based on integrations, APIs, queries, and transactions. However, CIs also need to be mapped to a conceptional model or service to present the service and its many layers in an easily consumable way.

These services will need to be manually created or imported into the CMDB and manually connected to the application services. Services can be mapped to technical or business services or both.

If business services reporting has been requested, talk to the business to develop a list of services that will be required. Use terms the business will be expecting and identify which applications and instances will be mapped to those services.

If IT is using the CMDB to support service usage and reporting, develop the list of IT services and identify which applications and instances will be mapped to those services.

Work with your stakeholders to ensure catalog items make sense to them

There isn't a definitive right or wrong way to define catalog items. For example, the business and IT could both reference application servers, but only IT may need to see technical services broken down by specific locations or device types.

Refer back to your goals and use cases to think through how best to meet those objectives and determine how to categorize your services.

Define the services that will be the top-level, nondiscoverable services, which will group together the CIs that make up the complete service. Identify which application(s) will connect into the technical service.

When you are ready to start discovery, this list of services will be connected to the discovered data to organize it in a way that makes sense for how your stakeholders need to see the data.

While working toward meeting the goals of the first few use cases, you will want to keep the structure simple. Once processes are in place and data is regularly validated, complexities of different service types and names can be integrated into the data.

Define the service types to manage within the CMDB to logically group CIs

Determine which method of service groupings will best serve your audience for your prioritized use cases. This will help to name your service categories. Service types can be added as the CMDB evolves and as the audience changes.

2.1.1 Define and prioritize your services

Prioritize your starting point. If multiple audiences need to be accommodated, work with one group at a time.

Timing: will vary depending on number of services, and starting point

1. Create your list of services, referencing an existing service catalog, business continuity or disaster recovery plan, list of applications, or brainstorming sessions. Use the terminology that makes the most sense for the audience and their reporting requirements.
2. If this list is already in place, assess for relevance and reduce the list to only those services that will be managed through the CMDB.
3. Determine what data will be relevant for each service based on the exercises done in 1.1.4 and 1.1.5. For example, if priority was a required attribute for use case data, ensure each service lists the priority of that service.
4. For each of these, identify the supporting services. These items can come from your technical service catalog or list of systems and software.
5. Document this table in the Use Cases and Data Worksheet, tab 3: Service Catalog.

Service Record Example

Service: Email
Supporting Services: M365, Authentication Services

Service Attributes

Availability: 24/7 (99.999%)
Priority: Critical
Users: All
Used for: Collaboration
Billable: Departmental
Support: Unified Support Model, Account # 123456789

The CMDB will be organized by services and will enable data analysis through multiple categorization schemes

To extract maximum service management benefit from a CMDB, the highest level of CI type should be a service, as demonstrated below. While it is easier to start at the system or single-asset level, taking the service mapping approach will provide you with a useful and dynamic view of your IT environment as it relates to the services you offer, instead of a static inventory of components.

Level 1: Services

• Business Service Offering: A business service is an IT service that supports a business process, or a service that is delivered to business customers. Business service offerings typically are bound by service-level agreements.
• IT Service Offering: An IT service supports the customer's business processes and is made up of people, processes, and technology. IT service offerings typically are bound by service-level agreements.

Level 2: Infrastructure CIs

• IT Component Set: An IT service offering consists of one of more sets of IT components. An IT component set allows you to group or bundle IT components with other components or groupings.
• IT Component: An IT system is composed of one or more supporting components. Many components are shared between multiple IT systems.

Level 3: Supporting CIs

• IT Subcomponent: Any IT asset that is uniquely identifiable and a component of an IT system.
• IT components can have subcomponents, and those components can have subcomponents, etc.

Assess your CMDB's standard category offerings against your environment, with a plan to minimize customization

Standard categorization schemes will allow for easier integration with multiple tools and reporting and improve results if using machine learning to automate categorization. If the CMDB chosen includes structured categories, use that as your starting point and focus only on gaps that are not addressed for CIs unique to your environment.

There is an important distinction between a class and a type. This concept is foundational for your configuration data model, so it is important that you understand it.

• Types are general groupings, and the things within a type will have similarities. For attributes that you want to collect on a type, all children classes and CIs will have those attribute fields.
• Classes are a more specific grouping within a type. All objects within a class will have specific similarities. You can also use subclasses to further differentiate between CIs.
• Individual CIs are individual instances of a class or subclass. All objects in a class will have the same attribute fields and behave the same, although the values of their attributes will likely differ.
• Attributes may be discovered or nondiscoverable and manually added to CIs. The attributes are properties of the CI such as serial number, version, memory, processor speed, or asset tag.

Use inheritance structures to simplify your configuration data model.

Assess the list of classes of configuration items against your requirements

Types are general groupings, and the things within a type will have similarities. Each type will have its own table within the CMDB. Classes within a type are a more specific grouping of configuration items and may include subclasses.

Review your vendor's CMDB documentation. Find the list of CI types or classes. Most CMDBs will have a default set of classes, like this standard list. If you need to build your own, use the table below as a starting point. Define anything required for unique classes. Create a list and consult with your installation partner.

Sample list of classes organized by type

Review relationships to determine which ones will be most appropriate to map your dependencies

Your CMDB should include multiple relationship types. Determine which ones will be most effective for your environment and ensure everyone is trained on how to use them. As CIs are mapped, verify they are correct and only manually map what is incorrect or not mapping through automation.

Manually mapping CMDB relationships may be time consuming and prone to error, but where manual mapping needs to take place, ensure the team has a common view of the dependency types available and what is important to map.

Use automated mapping whenever possible to improve accuracy, provide functional visualizations, and enable dynamic updates as the environment changes.

Where a dependency maps to external providers, determine where it makes sense to discover and map externally provided CIs.

• Only connect where there is value in mapping to vendor-owned systems.
• Only connect where data and connections can be trusted and verified.

Most common dependency mapping types

2.1.2 Test configuration items against existing categories

Time to complete: 1-2 hours

1. Select a service to test.
2. Identify the various components that make up the service, focusing on configuration items, not attributes
3. Categorize configuration items against types and classes in the default settings of the CMDB.
4. Using the default relationships within the CMDB, identify the relationships between the configuration items.
5. Identify types, classes, and relationships that do not fit within the default settings. Determine if there are common terms for these items or determine most appropriate name.
6. Validate these exceptions with the publisher.
7. Document exceptions in the Configuration Management Standard Operating Procedures, Appendix 2: Types and Classes of Configuration Items

2.1.3 Create a configuration control board charter to define the board's responsibilities and protocols

A charter will set the tone for meetings, ensure purpose is defined and meeting cadence is set for regular reviews.

1. Open the Configuration Control Board Charter. Review the document and modify as appropriate for your CCB. This will include:
   • Purpose and mandate of the committee – Reference objectives from the project charter.
   • Team composition – Determine the right mix of team members. A team of six to ten people can provide a good balance between having a variety of opinions and getting work done.
   • Voting option – Determine the right quorum to approve changes.
   • Responsibilities – List responsibilities, starting with RACI chart items.
   • Authority – Define the control board's span of control.
   • Governing laws and regulations – List any regulatory requirements that will need to be met to satisfy your auditors.
   • Meeting preparation – Set expectations to ensure meetings are productive.
2. Distribute the charter to CCB members.

Assess the default list of statuses for each state

Align this list with your CMDB

Minimize the number of customizations that will make it difficult to update the platform.

1. Review the default status list within the tool.
2. Identify which statuses will be most used. Write a definition for each status.
3. Update this list as you update process documentation in Step 3.1. After initial implementation, this list should only be modified through change enablement.
4. Record this list of statuses in the Configuration Management Standard Operating Procedures, Appendix 4: Statuses

Step 2.2

Document statuses, attributes, and data sources

Activities

2.2.1 Follow the packet and map out the in-scope services and data centers

2.2.2 Build data model diagrams

2.2.3 Determine access rights for your data

This step will walk you through the following aspects of a configuration management system:

• Statuses
• Attributes for each class of CI

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• Project manager

Outcomes of this step

• Framework for approaching CI statuses
• Attributes for each class of CI
• Data sources for those attributes

Service mapping approaches

As you start thinking about dependency mapping, it's important to understand the different methods and how they work, as well as your CMDB's capabilities. These approaches may be all in the same tool, or the tool may only have the top-down options.

Model hierarchy

Automated data mapping will be helpful, but it won't be foolproof. It's critical to understand the data model to validate and map nondiscoverable CIs correctly.

The framework consists of the business, enterprise, application, and implementation layers.

The business layer encodes real-world business concepts via the conceptual model.

The enterprise layer defines all enterprise data assets' details and their relationships.

The application layer defines the data structures as used by a specific application.

The implementation layer defines the data models and artifacts for use by software tools.

Learn how to create data models with Info-Tech's blueprint Create and Manage Enterprise Data Models

2.2.1 Follow the packet and map out the in-scope services and data centers

Reference your network topology and architecture diagrams.

Allot 1 hour for this activity.

1. Start with a single service that is well understood and documented.
2. Identify the technical components (hardware and applications) that make up the service.
3. Determine if there is a need to further break down services into logical service groupings. For example, the email service to the right is broken down into authentication and mail flow.
4. If you don't have a network diagram to follow, create a simple one to identify workflows within the service and components the service uses.
5. Record the apps and underlying components in the Configuration Management Standard Operating Procedures, Appendix 1: Configuration Data Model Structure.

This information will be used for CM project planning and validating the contents of the CMDB.

Download the Configuration Management Diagram Template Library to see an example.

Build your configuration data model

Rely on out-of-the-box functionality where possible and keep a narrow focus in the early implementation stages.

1. If you have an enterprise architecture, then your configuration management data model should align with it.
2. Keep a narrow focus in the early implementation stages. Don't fill up your CMDB until you are ready to validate and fix the data.
3. Rely on out-of-the-box (OOTB) functionality where possible. If your configuration management database (CMDB) and platform do not have a data model OOTB, then rely on a publicly available data model.
4. Map your business or IT service offering to the first few layers.

Once this is built out in the system, you can let the automated dependency mapping take over, but you will still need to validate the accuracy of the automated mapping and investigate anything that is incorrect.

Sample Configuration Data Model

Every box represents a CI, and every line represents a relationship

Example: Data model and CMDB visualization

Once the data model is entered into the CMDB, it will provide a more dynamic and complex view, including CIs shared with other services.

CMDB View

2.2.2 Build data model diagrams

Visualize the expected CI classes and relationships.

Allot 45 minutes.

1. Identify the different data model views you need. Use multiple diagrams to keep the information simple to read and understand. Common diagrams include:

1. Network level: Outline expected CI classes and relationships at the network level.
2. Application level: Outline the expected components and relationships that make up an application.
3. Services level: Outline how business capability CIs and service CIs relate to each other and to other types of CIs.

2. Use boxes to represent CI classes.
3. Use lines to represent relationships. Include details such as:

1. Relationship name: Write this name on the arrow.
2. Direction: Have an arrow point to each child.

Review samples in Configuration Management Diagram Template Library.
Record these diagrams in the Configuration Management Standard Operating Procedures, Appendix 1: Configuration Data Model Structure.

Download the Configuration Management Diagram Template Library to see examples.

Determine governance for data security, access, and validation

Align CMDB access to the organization's access control policy to maintain authorized and secure access for legitimate staff performing their role.

2.2.3 Determine access rights for your data

Allot 30 minutes for this discussion.

1. Open the Configuration Management Standard Operating Procedures, section 5: Access Rights.
2. Review the various roles from an access perspective.

1. Who needs read-only access?
2. Who needs read/write access?
3. Should there be restrictions on who can delete data?

3. Fill in the chart and communicate this to your CMDB installation vendor or your CMDB administrator.

Phase 3

Configuration Record Updates

This phase will walk you through the following aspects of a configuration management system:

• ITSM Practices and Workflows
• Discovery and Dependency Mapping Tools
• Auditing and Data Validation Practices

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• SCM project manager
• IT audit

Harness Service Configuration Management Superpowers

Step 3.1

Keep CIs and relationships up to date through lifecycle process integrations

Activities

3.1.1 Define processes to bring new services into the CMDB

3.1.2 Determine when each type of CI will be created in the CMDB

3.1.3 Identify when each type of CI will be retired in the CMDB

3.1.4 Record when and how attributes will change

3.1.5 Institute configuration control and configuration baselines

This step will walk you through the following aspects of a configuration management system:

1. ITSM Practices and Workflows
2. Discovery and Dependency Mapping Tools

This phase involves the following participants:

1. IT service owners
2. Enterprise architects
3. Practice owners and managers
4. SCM practice manager
5. Project manager

Outcomes of this step

• List of action items for updating interfacing practices and processes
• Identification of where configuration records will be manually updated

Incorporate CMDB updates into IT operations

Determine which processes will prompt changes to the CMDB data

	Change enablement	Identify which process are involved in each stage of data input, maintenance, and removal to build out a process for each scenario.
	Project management
	Change enablement	Asset management	Security controls
	Project management	Incident management	Deployment management
	Change enablement	Asset management	Security controls
	Project management	Incident management	Service management

Formalize the process for adding new services to the CMDB

As new services and products are introduced into the environment, you can improve your ability to correctly cost the service, design integrations, and ensure all operational capabilities are in place, such as data backup and business continuity plans.
In addition, attributes such as service-level agreements (SLAs), availability requirements, and product, technical, and business owners should be documented as soon as those new systems are made live.

• Introduce the technical team and CCB to the product early to ensure the service record is created before deployment and to quickly map the services once they are moved into the production environment.
• Engage with project managers or business analysts to define the process to include security and technical reviews early.
• Engage with the security and technical reviewers to start documenting the service as soon as it is approved.
• Determine which practices will be involved in the creation and approval of new services and formalize the process to streamline entry of the new service, onboarding corresponding CIs and mapping dependencies.

3.1.1 Define processes to bring new services into the CMDB

Start with the most frequent intake methods, and if needed, use this opportunity to streamline the process.

1. Discuss the methods for new services to be introduced to the IT environment.
2. Critique existing methods to assess consistency and identify issues that could prevent the creation of services in the CMDB in a timely manner.
3. Create a workflow for the existing processes, with an eye to improvement. Identify any changes that will need to be introduced and managed appropriately.
4. Identify where additional groups may need to be engaged to ensure success. For example, if project managers are not interfacing early with IT, discuss process changes with them.
5. Discuss the validation process and determine where control points are. Document these on the workflows.
6. Complete the Configuration Management Standard Operating Procedures, section 8.1: Introduce New Service and Data Model.

Possible intake opportunities:

• Business-driven project intake process
• IT-driven project intake process
• Change enablement reviews
• Vendor-driven product changes

Identify scenarios where CIs are added and removed in the configuration management database

New CIs may be introduced with new services or may be introduced and removed as part of asset refreshes or through service restoration in incident management. Updates may be done by your own services team or a managed services provider.
Determine the various ways the CIs may be changed and test with various CI types.
Review attributes such as SLAs, availability requirements, and product, technical, and business owners to determine if changes are required.

• Identify what will be updated automatically or manually. Automation could include discovery and dependency mapping or synchronization with AMDB or AIOps tools.
• Engage with relevant program managers to define and validate processes.
• Identify control points and review audit requirements.

Info-Tech Insight

Data deemed no longer current may be archived or deleted. Retained data may be used for tracing lifecycle changes when troubleshooting or meeting audit obligations. Determine what types of CIs and use cases require archived data to meet data retention policies. If none do, deletion of old data may be appropriate.

3.1.2 Identify when each type of CI will be created in the CMDB

Allot 45 minutes for discussion.

1. Discuss the various methods for new CIs to be introduced to the IT environment.
2. Critique existing methods to assess consistency and identify issues that could prevent the creation of CIs in the CMDB in a timely manner.
3. Create a workflow for the existing processes, with an eye to improvement. Identify any changes that will need to be introduced and managed appropriately.
4. Identify where additional groups may need to be engaged to ensure success. For example, if project managers are not interfacing early with IT, discuss process changes with them.
5. Discuss the validation process and determine where control points are. Document these on the workflows.
6. Complete Configuration Management Standard Operating Procedures, section 8.2: Introduce New Configuration Items to the CMDB

Possible intake opportunities:

• Business-driven project intake process
• IT-driven project intake process
• Change enablement reviews
• Vendor-driven product changes
• Incident management
• Asset management, lifecycle refresh

3.1.3 Identify when each type of CI will be retired in the CMDB

Allot 45 minutes for discussion.

1. Discuss the various methods for CIs to be removed from the IT environment.
2. Critique existing methods to assess consistency and identify issues that could prevent the retirement of CIs in the CMDB in a timely manner.
3. Create a workflow for the existing processes, with an eye to improvement. Identify any changes that will need to be introduced and managed appropriately.
4. Identify where additional groups may need to be engaged to ensure success. For example, if project managers are not interfacing early with IT, discuss process changes with them.
5. Discuss the validation process and determine where control points are. Document these on the workflows.
6. Discuss data retention. How long will retired information need to be archived? What are the potential scenarios where legacy information may be needed for analysis?
7. Complete the Configuration Management Standard Operating Procedures, section 8.4: Retire and Archive Configuration Records.

Possible retirement scenarios:

• Change enablement reviews
• Vendor-driven product changes
• Incident management
• Asset management, lifecycle refresh

Determine appropriate actions for detecting new or changed CIs through discovery

Automated detection will provide the most efficient way of recording planned changes to CIs as well as detected unplanned changes. Check with the tool to determine what reports or notifications are available for the configuration management process and define what actions will be appropriate.

As new CIs are detected, identify the process by which they should have been introduced into configuration management and compare against those records. If your CMDB can automatically check for documentation, this may be easier. Weekly reporting will allow you to catch changes quickly, and alerts on critical CIs could enable faster remediation, if the tool allows for alerting. AIOps could identify, notify of, and process many changes in a highly dynamic environment.

The configuration manager may not have authority to act but can inform the process owners of unauthorized changes for further action. Once the notifications are forwarded to the appropriate process owner, the configuration manager will note the escalation and follow up on data corrections as deemed appropriate by the associated process owner.

3.1.4 Record when and how attributes will change

These lists will help with configuration control plans and your implementation roadmap.

1. List each attribute that will change in that CI type's life.
2. Write all the times that each attribute will change. Identify:

1. The name of the workflow, service request, process, or practice that modifies the attribute.
2. Whether the update is made automatically or manually.
3. The role or tool that updates the CMDB.

3. Update the relevant process or procedure documentation. Explicitly identify when the configuration records are updated.

Document these tables in Configuration Management Standard Operation Procedures, Section 8.7: Practices That Modify CIs.

Institute configuration control and configuration baselines where appropriate

A baseline enables an assessment of one or more systems against the desired state and is useful for troubleshooting incidents or problems and validating changes and security settings.

Baselines may be used by enterprise architects and system engineers for planning purposes, by developers to test their solution against production copies, by technicians to assess configuration drift that may be causing performance issues, and by change managers to assess and verify the configuration meets the target design.

Configuration baselines are a snapshot of configuration records, displaying attributes and first-level relationships of the CIs. Standard configurations may be integral to the success of automated workflows, deployments, upgrades, and integrations, as well as prevention of security events. Comparing current CIs against their baselines will identify configuration drift, which could cause a variety of incidents. Configuration baselines are updated through change management processes.
Configuration baselines can be used for a variety of use cases:

• Version control – Management of software and hardware versions, https://dj5l3kginpy6f.cloudfront.net/blueprints/harness-configuration-management-superpowers-phases-1-4/builds, and releases.
• Access control – Management of access to facilities, storage areas, and the CMS.
• Deployment control – Take a baseline of CIs before performing a release so you can use this to check against actual deployment.
• Identify accidental changes – Everyone makes mistakes. If someone installs software on the wrong server or accidentally drops a table in a database, the CMS can alert IT of the unauthorized change (if the CI is included in configuration control).

Info-Tech Insight

Determine the appropriate method for evaluating and approving changes to baselines. Delegating this to the CCB every time may reduce agility, depending on volume. Discuss in CCB meetings.

3.1.5 Institute configuration control and configuration baselines where appropriate

Only baseline CIs and relationships that you want to control through change enablement.

1. Determine criteria for capturing configuration baselines, including CI type, event, or processes.
2. Identify who will use baselines and how they will use the data. Identify their needs.
3. Identify CIs that will be out of scope and not have baselines created.
4. Document requirements in the SOP.
5. Ensure appropriate team members have training on how to create and capture baselines in the CMDB.
6. Document in the Configuration Management Standard Operating Procedures, section 8.5: Establish and Maintain Configuration Baselines.

Step 3.2

Validate data within the CMDB

Activities

3.2.1 Build an audit plan and checklist

This step will walk you through the following aspects of a configuration management system:

• Data validation and audit

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• Project manager
• IT audit

Outcomes of this step

• Updates to processes for data validation
• Plan for auditing and validating the data in the CMDB

Audit and validate the CMDB

Review the performance of the supporting technologies and processes to validate the accuracy of the CMDB.

CM Audit Plan

• CM policies
• CM processes and procedures
• Interfacing processes
• Content within the CMDB

"If the data in your CMDB isn't accurate, then it's worthless. If it's wrong or inaccurate, it's going to drive the wrong decisions. It's going to make IT worse, not better."
– Valence Howden, Research Director, Info-Tech Research Group

Ensure the supporting technology is working properly

Does the information in the database accurately reflect reality?

Perform functional tests during audits and as part of release management practices.

Audit results need to have a clear status of "compliant," "noncompliant," or "compliant with conditions," and conditions need to be noted. The conditions will generally offer a quick win to improve a process, but don't use these audit results to quickly check off something as "done." Ensure the fix is useful and meaningful to the process.
The audit should cover three areas:

• Process: Are process requirements for the program well documented? Are the processes being followed? If there were updates to the process, were those updates to the process documented and communicated? Has behavior changed to suit those modified processes?
• Physical: Physical configuration audits (PCAs) are audits conducted to verify that a configuration item, as built, conforms to the technical documentation that defines and describes it.
• Functional: Functional configuration audits (FCAs) are audits conducted to verify that the development of a configuration item has been completed satisfactorily, the item has achieved the functional attributes specified in the functional or allocated baseline, and its technical documentation is complete and satisfactory.

Build auditing and validation of processes whenever possible

When technicians and analysts are working on a system, they should check to make sure the data about that system is correct. When they're working in the CMDB, they should check that the data they're working with is correct.

More frequent audits, especially in the early days, may help move toward process adoption and resolving data quality issues. If audits are happening more frequently, the audits can include a smaller scope, though it's important to vary each one to ensure many different areas have been audited through the year.

• Watch for data duplication from multiple discovery tools.
• Review mapping to ensure all relevant CIs are attached to a product or service.
• Ensure report data is logical.

Ensure the supporting technology is working properly

Does the information in the database accurately reflect reality?

Perform functional tests during audits and as part of release management practices.

Audit results need to have a clear status of "compliant," "noncompliant," or "compliant with conditions," and conditions need to be noted. The conditions will generally offer a quick win to improve a process, but don't use these audit results to quickly check off something as "done." Ensure the fix is useful and meaningful to the process.
The audit should cover three areas:

• Process: Are process requirements for the program well documented? Are the processes being followed? If there were updates to the process, were those updates to the process documented and communicated? Has behavior changed to suit those modified processes?
• Physical: Physical configuration audits (PCAs) are audits conducted to verify that a configuration item, as built, conforms to the technical documentation that defines and describes it.
• Functional: Functional configuration audits (FCAs) are audits conducted to verify that the development of a configuration item has been completed satisfactorily, the item has achieved the functional attributes specified in the functional or allocated baseline, and its technical documentation is complete and satisfactory.

More frequent audits, especially in the early days, may help move toward process adoption and resolving data quality issues. If audits are happening more frequently, the audits can include a smaller scope, though it's important to vary each one to ensure many different areas have been audited through the year.

• Watch for data duplication from multiple discovery tools.
• Review mapping to ensure all relevant CIs are attached to a product or service.
• Ensure report data is logical.

Identify where processes break down and data is incorrect

Once process stops working, data becomes less accurate and people find workarounds to solve their own data needs.

Data within the CMDB often becomes incorrect or incomplete where human work breaks down

• Investigate processes that are performed manually, including data entry.
• Investigate if the process executors are performing these processes uniformly.
• Determine if there are opportunities to automate or provide additional training.
• Select a sample of the corresponding data in the CMS. Verify if the data is correct.

Non-CCB personnel may not be completing processes fully or consistently

• Identify where data in the CMS needs to be updated.
• Identify whether the process practitioners are uniformly updating the CMS.
• Discuss options for improving the process and driving consistency for data that will benefit the whole organization.

Ensure that the data entered in the CMDB is correct

• Confirm that there is no data duplication. Data duplication is very common when there are multiple discovery tools in your environment. Confirm that you have set up your tools properly to avoid duplication.
• Build a process to respond to baseline divergence when people make changes without following change processes and when updates alter settings.
• Audit the system for accuracy and completeness.

3.2.1 Build an audit plan and checklist

Use the audit to identify areas where processes are breaking down.

Audits present you with the ability to address these pain points before they have greater negative impact.

1. Identify which regulatory requirements and/or auditing bodies will be relevant to audit processes or findings.
2. Determine frequency of practice audits and how they relate to internal audits or external audits.
3. Determine audit scope, including requirements for data spot checks.
4. Determine who will be responsible for conducting audits and validate this is consistent with the RACI chart.
5. Record audit procedures in the Configuration Management Standard Operating Procedures section 8.6: Verify and Review the Quality of Information Through Auditing.
6. Review the Configuration Management Audit and Validation Checklist and modify to suit your needs.

Download the Configuration Management Audit and Validation Checklist

Phase 4

Service Configuration Roadmap

This phase will walk you through the following aspect of a configuration management system:
Roadmap
This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• SCM project manager

Harness Service Configuration Management Superpowers

Step 4.1

Define measures of success

Activities

4.1.1 Identify key metrics to define configuration management success
4.1.2 Brainstorm and record desired reports, dashboards, and analytics
4.1.3 Build a configuration management policy

This phase will walk you through the following aspects of a configuration management system:

• Metrics
• Policy

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• SCM project manager

The value of metrics can be found in IT efficiency increases

When determining metrics for configuration management, be sure to separate metrics needed to gauge configuration management success and those that will use data from the CMDB to provide metrics on the success of other practices.

• Metrics provide accurate indicators for IT and business decisions.
• Metrics help you identify IT efficiencies and problems and solve issues before they become more serious.
• Active metrics tracking makes root cause analysis of issues much easier.
• Proper application of metrics helps IT services identification and prioritization.
• Operational risks can be prevented by identifying and implementing metrics.
• Metrics analysis increases the confidence of the executive team and ensures that IT is working well.

4.1.1 Identify key metrics to define configuration management success

Determine what metrics are specifically related to the practice and how and when metrics will be accessed.

Document metrics in the Configuration Management Standard Operating Procedures, section 7: Success Metrics

Use performance metrics to identify areas to improve service management processes using CMDB data

Metrics can indicate a problem with service management processes but cannot provide a clear path to a solution on their own.

• The biggest challenge is defining and measuring the process and people side of the equation.
• Expected performance may also need to be compared to actual performance in planning, budgeting, and improvements.
• The analysis will need to include critical success factors (CSFs), data collection procedures, office routines, engineering practices, and flow diagrams including workflows and key relationships.
• External benchmarking may also prove useful in identifying how similar organizations are managing aspects of their infrastructure, processing transactions/requests, or staffing. If using external benchmarking for actual process comparisons, clearly defining your internal processes first will make the data collection process smoother and more informative.

Info-Tech Insight

Using a service framework such as ITIL, COBIT, or ISO 20000 may make this job easier, and subscribing to benchmarking partners will provide some of the external data needed for comparison.

4.1.2 Brainstorm and record desired reports, dashboards, and analytics with related practices

The project team will use this list as a starting point

Allot 45 minutes for this discussion.

1. Create a table for each service or business capability.
   1. Have one column for each way of consuming data: reports, dashboards, and ad hoc analytics.
   2. Have one row for each stakeholder group that will consume the information.
2. Use the challenges and use cases to brainstorm reports, dashboards, and ad hoc analytic capabilities that each stakeholder group will find useful.
3. Record these results in your Configuration Management Standard Operating Procedures, section 7: Aligned Processes' Desired Analytical Capabilities.

Download the blueprint Take Control of Infrastructure and Operations Metrics to create a complete metrics program.

Create a configuration management policy and communicate it

Policies are important documents to provide definitive guidelines and clarity around data collection and use, process adherence, and controls.

• A configuration management policy will apply to IT as the audience, and participants in the program will largely be technical.
• Business users will benefit from a great configuration management program but will not participate directly.
• The policy will include objectives and scope, use of data, security and integrity of data, data models and criteria, and baseline configurations.
• Several governing regulations and practices may intersect with configuration management, such as ITIL, COBIT, and NIST frameworks, as well as change enablement, quality management, asset management, and more.
• As the policy is written, review processes to ensure policies and processes are aligned. The policy should enable processes, and it may require modifications if it hinders the collection, security, or use of data required to meet proposed use cases.
• Once the policy is written and approved, ensure all stakeholders understand the importance, context, and repercussions of the policy.

The approvals process is about appropriate oversight of the drafted policies. For example:

• Do the policies satisfy compliance and regulatory requirements?
• Do the policies work with the corporate culture?
• Do the policies address the underlying need?

If the draft is approved:

• Set the effective date and a review date.
• Begin communication, training, and implementation.

Employees must know that there are new policies and understand the steps they must take to comply with the policies in their work.

Employees must be able to interpret, understand, and know how to act upon the information they find in the policies.

Employees must be informed on where to get help or ask questions and who to request policy exceptions from.

If the draft is rejected:

• Acquire feedback and make revisions.
• Resubmit for approval.

4.1.3 Build a configuration management policy

This policy provides the foundation for configuration control.

Use this template as a starting point.

The Configuration Management Policy provides the foundation for a configuration control board and the use of configuration baselines.
Instructions:

1. Review and modify the policy statements. Ensure that the policy statements reflect your organization and the expectations you wish to set.
2. If you don't have a CCB: The specified responsibilities can usually be assigned to either the configuration manager or the governing body for change enablement.
3. Determine if you should apply this policy beyond SCM. As written, this policy may provide a good starting point for practices such as:
   • Secure baseline configuration management
   • Software configuration management

Download the Configuration Management Policy template

Step 4.2

Build communications and a roadmap

Activities

4.2.1 Build a communications plan
4.2.2 Identify milestones

This phase will walk you through the following aspects of a configuration management system:

• Communications plan
• Roadmap

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• SCM project manager

Outcomes of this step

• Documented expectations around configuration control
• Roadmap and action items for the SCM project

Do not discount the benefits of a great communications plan as part of change management

Many configuration management projects have failed due to lack of organizational commitment and inadequate communications.

• Start at the top to ensure stakeholder buy-in by verifying alignment and use cases. Without a committed project sponsor who believes in the value of configuration management, it will be difficult to draw the IT team into the vision.
• Clearly articulate the vision, strategy, and goals to all stakeholders. Ensure the team understands why these changes are happening, why they are happening now, and what outcomes you hope to achieve.
• Gain support from technical teams by clearly expressing organizational and departmental benefits – they need to know "what's in it for me."
• Clearly communicate new responsibilities and obligations and put a feedback process in place to hear concerns, mitigate risk, and act on opportunities for improvement. Be prepared to answer questions as this practice is rolled out.
• Be consistent in your messaging. Mixed messages can easily derail progress.
• Communicate to the business how these efforts will benefit the organization.
• Share documents built in this blueprint or workshop with your technical teams to ensure they have a clear picture of the entire configuration management practice.
• Share your measures and view of success and communicate wins throughout building the practice.

For a more detailed program, see Drive Technology Adoption

Formulate a communications plan to ensure all stakeholders and impacted staff will be aware of the plan

Communication is key to success in process adoption and in identifying potential risks and issues with integration with other processes. Engage as often as needed to get the information you need for the project and for adoption.

Identify Messages

Distinct information that needs to be sent at various times. Think about:

• Who will be impacted and how.
• What the goals are for the project/new process.
• What the audience needs to know about the new process and how they will interface with each business unit.
• How people can request configuration data.

Identify Audiences

Any person or group who will be the target of the communication. This may include:

• Project sponsors and stakeholders.
• IT staff who will be involved in the project.
• IT staff who will be impacted by the project (i.e. who will benefit from it or have obligations to fulfill because of it).
• Business sponsors and product owners.

Document and Track

Document messaging, medium, and responsibility, working with the communications team to refine messages before executing.

• Identify where people can send questions and feedback to ensure they have the information they need to make or accept the changes.
• Document Q&A and share in a central location.

Determine Timing

Successful communications plans consider timing of various messages:

• Advanced high-level notice of improvements for those who need to see action.
• Advanced detailed notice for those who will be impacted by workload.
• Advanced notice for who will be impacted (i.e. who will benefit from it or have obligations to fulfill because of it) once the project is ready to be transitioned to daily life.

Determine Delivery

Work with your communications team, if you have one, to determine the best medium, such as:

• Meeting announcement for stakeholders and IT.
• Newsletter for those less impacted.
• Intranet announcements: "coming soon!"
• Demonstrations with vendors or project team.

4.2.1 Build a communications plan

The communications team will use this list as a starting point.

Allot 45 minutes for this discussion.

Identify stakeholders.

1. Identify everyone who will be affected by the project and by configuration management.

Craft key messages tailored to each stakeholder group.

1. Identify the key messages that must be communicated to each group.

Finalize the communication plan.

1. Determine the most appropriate timing for communications with each group to maximize receptivity.
2. Identify any communication challenges you anticipate and incorporate steps to address them into your communication plan.
3. Identify multiple methods for getting the messages out (e.g. newsletters, emails, meetings).

3. Identify how feedback will be collected (i.e. through interviews or surveys) to measure whether the changes were communicated well.

Build a realistic, high-level roadmap including milestones

Break the work into manageable pieces

1. Plan to have multiple phases with short-, medium-, and long-term goals/timeframes. Building a CMDB is not easy and should be broken into manageable sections.
2. Set reasonable milestones. For each phase, document goals to define "done" and ensure they're reasonable for the resources you have available. If working with a vendor, include them in your discussions of what's realistic.
3. Treat the first phase as a pilot. Focus on items you understand well:
   1. Well-understood user-facing and IT services
   2. High-maturity management and governance practices
   3. Trusted data sources
4. Capture high-value, high-criticality services early. Depending on the complexity of your systems, you may need to split this phase into multiple phases.

Document this table in the Configuration Management Project Charter, section 3.0: Milestones

4.2.2 Identify milestones

Build out a high-level view to inform the project plan

Open the Configuration Management Project Charter, section 3: Milestones.
Instructions:

1. Identify high-level milestones for the implementation of the configuration management program. This may include tool evaluation and implementation, assignment of roles, etc.
2. Add details to fill out the milestone, keeping to a reasonable level of detail. This may inform vendor discussion or further development of the project plan.
3. Add target dates to the milestones. Validate they are realistic with the team.
4. Add notes to the assumptions and constraints section.
5. Identify risks to the plan.

Download the Configuration Management Project Charter

Workshop Participants

R = Recommended
O = Optional

Related Info-Tech Research

• Develop an IT Asset Management Strategy
• Implement Hardware Asset Management
• Implement Software Asset Management
• Optimize IT Change Management
• Drive Technology Adoption
• Improve Incident and Problem Management

Research Contributors and Experts

Thank you to everyone who contributed to this publication

Brett Johnson, Senior Consultant, VMware

Yev Khovrenkov, Senior Consultant, Solvera Solutions

Larry Marks, Reviewer, ISACA New Jersey

Darin Ohde, Director of Service Delivery, GreatAmerica Financial Services

Jim Slick, President/CEO, Slick Cyber Systems

Emily Walker, Sr. Digital Solution Consultant, ServiceNow

Valence Howden, Principal Research Director, Info-Tech Research Group

Allison Kinnaird, Practice Lead, IT Operations, Info-Tech Research Group

Robert Dang, Principal Research Advisor, Security, Info-Tech Research Group

Monica Braun, Research Director, IT Finance, Info-Tech Research Group

Jennifer Perrier, Principal Research Director, IT Finance, Info-Tech Research Group

Plus 13 anonymous contributors

Bibliography

An Introduction to Change Management, Prosci, Nov. 2019.
BAI10 Manage Configuration Audit Program. ISACA, 2014.
Bizo, Daniel, et al, "Uptime Institute Global Data Center Survey 2021." Uptime Institute, 1 Sept. 2021.
Brown, Deborah. "Change Management: Some Statistics." D&B Consulting Inc. May 15, 2014. Accessed June 14, 2016.
Cabinet Office. ITIL Service Transition. The Stationery Office, 2011.
"COBIT 2019: Management and Governance Objectives. ISACA, 2018.
"Configuration Management Assessment." CMStat, n.d. Accessed 5 Oct. 2022.
"Configuration Management Database Foundation." DMTF, 2018. Accessed 1 Feb. 2021.
Configuration Management Using COBIT 5. ISACA, 2013.
"Configuring Service Manager." Product Documentation, Ivanti, 2021. Accessed 9 Feb. 2021.
"Challenges of Implementing configuration management." CMStat, n.d. Accessed 5 Oct. 2022.
"Determining if configuration management and change control are under management control, part 1." CMStat, n.d. Accessed 5 Oct. 2022.
"Determining if configuration management and change control are under management control, part 2." CMStat, n.d. Accessed 5 Oct. 2022.
"Determining if configuration management and change control are under management control, part 3." CMStat, n.d. Accessed 5 Oct. 2022.
"CSDM: The Recipe for Success." Data Content Manager, Qualdatrix Ltd. 2022. Web.
Drogseth, Dennis, et al., 2015, CMDB Systems: Making Change Work in the Age of Cloud and Agile. Morgan Kaufman.
Ewenstein, B, et al. "Changing Change Management." McKinsey & Company, 1 July 2015. Web.
Farrell, Karen. "VIEWPOINT: Focus on CMDB Leadership." BMC Software, 1 May 2006. Web.
"How to Eliminate the No. 1 Cause of Network Downtime." SolarWinds, 4 April 2014. Accessed 9 Feb. 2021.
"ISO 10007:2017: Quality Management -- Guidelines for Configuration Management." International Organization for Standardization, 2019.
"IT Operations Management." Product Documentation, ServiceNow, version Quebec, 2021. Accessed 9 Feb. 2021.
Johnson, Elsbeth. "How to Communicate Clearly During Organizational Change." Harvard Business Review, 13 June 2017. Web.
Kloeckner, K. et al. Transforming the IT Services Lifecycle with AI Technologies. Springer, 2018.
Klosterboer, L. Implementing ITIL Configuration Management. IBM Press, 2008.
Norfolk, D., and S. Lacy. Configuration Management: Expert Guidance for IT Service Managers and Practitioners. BCS Learning & Development Limited, revised ed., Jan. 2014.
Painarkar, Mandaar. "Overview of the Common Data Model." BMC Documentation, 2015. Accessed 1 Feb. 2021.
Powers, Larry, and Ketil Been. "The Value of Organizational Change Management." Boxley Group, 2014. Accessed June 14, 2016.
"Pulse of the Profession: Enabling Organizational Change Throughout Strategic Initiatives." PMI, March 2014. Accessed June 14, 2016.
"Service Configuration Management, ITIL 4 Practice Guide." AXELOS Global Best Practice, 2020
"The Guide to Managing Configuration Drift." UpGuard, 2017.