Process Overview: Configuration Management

Summary

Configuration Management (CM) is a process used to manage the configuration of services down to the level of individual configuration items (CI). The process involves managing and tracking every configuration item (CI) from initiation to retirement to ensure organizations have a comprehensive understanding of their services, configuration items running the services, and interdependencies. This understanding is critical for making informed decisions about IT changes, ensuring compliance with industry standards and regulations and maintaining overall IT service quality. By effectively managing CIs, organizations can minimize risks associated with changes, optimize IT asset utilization, and facilitate quicker resolution of IT issues, thereby supporting the business's seamless operation and strategic objectives.

The result of the Configuration Management process is the creation of the Configuration Management Database (CMDB). The CMDB is a comprehensive repository that stores detailed information about each CI. It includes data on CIs such as servers, applications, and IT services. The CMDB is vital in illustrating the relationships and dependencies among these IT components. This information is invaluable for effective problem-solving and for making informed decisions regarding changes or updates to the IT infrastructure. It plays a key role in enhancing the efficiency and reliability of IT services within an organization.

Configuration Management and IT Asset Management (ITAM) are closely related. Both processes help companies ensure their IT landscape supports business processes as efficiently as possible. However, they are separate processes that approach asset and configuration items from different angles. 

The CM process focuses on providing accurate and reliable information about the configuration needed for various services and ensuring the Configuration Items (CI) taking part in the service provision are always available. Also, it includes essential information about the relationships between CIs, which helps assess the impact of changes related to CIs and services. On the other hand, ITAM is concerned, for example, with the assets' value, location, ownership, and lifecycle aspects. ITAM answers questions like “Where are the assets located?”, “What is the value of these assets?", “When does the warranty of these devices end, and when do we have to replace them?” and so on.

Both processes are crucial for other service management processes, such as Incident, Problem, and Change management. They allow support teams to resolve incidents faster and help IT teams minimize the adverse impact of changes in the IT landscape. The figure below provides an overview of both processes and demonstrates that both processes typically involve discoverable and undiscoverable data.   

It's important to note that the processes overlap to a certain extent. For example, an application server is a concrete asset that some organization owns. It is located somewhere and has an intrinsic value that needs to be known and managed. However, the application server is also a CI that is managed by the CM process. The service is a critical component for running a certain service, and its dependencies to other CIs (such as other servers, database servers, databases, networks, and integrations) must be known and managed. Also, the availability and stability of the server and its dependencies must be managed. 

The Software Asset Management (SAM) process is also related to both CM and ITAM. SAM process focuses on managing software assets, such as software licenses. The following table summarizes the differences between Configuration Management, IT Asset Management, and Software Asset Management. 

IT Asset Management, Configuration Management, and their Relation to the CMDB  

As mentioned above, CM and ITAM are separate processes with commonalities and some overlap. The CM process typically manages many IT Assets managed by the ITAM process to ensure the relationships and dependencies related to service delivery are known and to ensure that the CIs are available and operational. 

The term Configuration Management Database (CMDB) is common in the context of the aforementioned processes. As mentioned above, the CMDB can be seen as an outcome of the Configuration Management Process and, as a concept, should not be confused with the IT Asset Management process. However, from a technical perspective, the IT Assets are stored as datacards in the CMDB module of the Matrix42 Service Management Tool. This, however, is visible only to administrators.

Configuration Management in Matrix42

Matrix42's solution offers tools that help organizations carry out their Configuration Management (CM) process effectively, as detailed in previous sections. It features a Configuration Management Database (CMDB) that helps manage, track, and show how different Configuration Items (CIs) are related. At the heart of this system is the service catalog. This is crucial not just for the CM process but also for other service management processes. It is important that all IT services are well-documented and stored in the CMDB for easy access and management. The solution allows applying customer-specific configurations that consider regulatory requirements.

The CMDB allows organizations to track a variety of CIs. Below are examples of CI types that can be managed within the CM process. Please note that the flexible data models allows the CMDB to be expanded to suit a variety of business needs.    

• Service Catalog:
  • Services.
• Application management:
  • Applications.
  • Integrations.
• Infrastructure management:
  • Cloud infrastructures.
  • SaaS components.

The following diagram illustrates the aforementioned CI types and typical relations: 

Service Catalog

The service catalog is the starting point in configuration management. It lists all the services that an organization provides. For instance, 'Service A' is linked to 'Business Process A', and similarly, 'Service B' is related to 'Business Process B.' These services represent the offerings that support different business processes within the organization.

Application Management

The second layer deals with the applications that enable the services. 'Application Installation A' and 'Application Installation B' represent the software required for 'Service A' and 'Service B', respectively. These installations are sometimes interconnected, as shown by 'Integration A-B,' which implies that data or functionality flows between them. Moreover, some applications depend on other applications to function. For example, 'Application Installation A' relies on 'Application Installation C' and 'D,' indicating a need for these applications to operate effectively. Below is an overview of Configuration Management focusing on the Service Catalog, Application Management, and Asset Management aspects: 

Asset Management

Finally, we have asset management, focusing on the physical or virtual servers and other assets where the applications are hosted. 'Server A', 'Server B', 'Server C', and 'Server D' represent the infrastructure that supports the applications. Each application installation runs on a specific server, and managing these servers is crucial for the availability and performance of the applications. The solution also allows for managing and monitoring various other asset types. It is important to note that these assets are also maintained through the ITAM process. Examples of asset types that can be effectively managed within the CMDB include:

• Servers
• Databases
• Networks
• Network devices
• Storages
• Backup devices
• Documents
• Drives
• Mobile applications
• Suppliers (stored on the Company template)

Infrastructure and Supplier Management

In the diagram above, 'SaaS Component A' and 'Application Installation A' rely on the underlying infrastructure. 'SaaS Component A' runs on 'Cloud Infrastructure A', showcasing the shift towards cloud-based solutions. This infrastructure is then linked back to 'Supplier A', indicating that it is an external service provisioned by a third-party supplier. On the other hand, 'Application Installation A' operates on 'Server A', which might represent an on-premises or private cloud server, and it is associated with 'Supplier B'.

Integration and Relationships

The diagram also shows an integration between 'Service A' and 'Service B', labeled as 'Integration A-B'. This represents a data or process flow between two distinct services, suggesting a dependency or collaboration between different applications or components of the services.

End-to-End Configuration Tracking

In essence, Matrix42's configuration management process tracks the relationships and dependencies from the service catalog right through to the suppliers. It ensures that every service is backed by the right applications, running on the correct infrastructure, and provided by reliable suppliers. This holistic approach provides clarity and control over the entire service delivery process, contributing to better service quality, risk management, and cost efficiency. The end result of this process is the formation of a Configuration Management Database (CMDB) that acts as a central repository for all configuration items (CI), reflecting the current state of service delivery components in real time.

Data Traceability and Compliance

The platform ensures full traceability by logging required instances of data access and modification. With a flexible permission scheme, you can control who can view or edit information. Additionally, the system’s customizability allows organizations to meet regulatory and compliance requirements across different industries.

Use Cases

1. Centralized configuration storage in the CMDB:
   1. Managing all CIs, IT assets, and service information in one place.
2. Service catalog management:
   1. Outlining service specifics, including relations, status, scope, and financial details.
3. Linkage to ITAM and application management:
   1. Record and track detailed asset and application information, supported by the ITAM process.
4. Extensive Reporting and Visualization:
   1. Comprehensive reports on CIs and visualization of dependencies.

Input Channels

CI data can be imported by various means, such as:

• One-time import from a file.
• Dynamic imports through discovery tools.
• Imports through integrations from other tools and systems.
• Manual entering of data in the Matrix42 Workspace.

Terminology

Prerequisites

• Understanding of IT services and infrastructure
  • An organization must have a clear comprehension of its IT services and infrastructure. This includes knowledge of what services are offered, the applications and hardware required to deliver these services, and the interdependencies between them.
• Detailed service catalog
  • A well-documented service catalog is essential. It should outline all the services provided by the IT department, capturing details such as service descriptions, dependencies, and associated business processes.
• Proper CMDB design that suits the organizational needs
  • The CMDB should be structured to accurately reflect the organization's assets and configuration items (CIs). It must be capable of illustrating the relationships and dependencies among these CIs.
• Integration capabilities
  • The organization must be able to integrate Matrix42’s CMDB with other tools and systems, such as discovery tools for automatic population and updates of the CIs.
• Roles and permissions setup
  • Defining roles and permissions is crucial for managing access to the CMDB. Different stakeholders may need varying levels of access and control over the data within the CMDB.
• Workflow and process definition
  • Clear workflows and processes should be established to handle the lifecycle of CIs, from their initiation, and changes throughout their lifespan to their retirement.
• Training and knowledge transfer
  • Ensuring that the IT staff is trained on how to use Matrix42 and understand the CM process is vital for a successful implementation.
• Initial data population
  • The CMDB must be populated with initial data, which may involve manual data entry or importing data from existing systems.

Benefits

• Improved service delivery
  • IT teams can ensure that services are delivered efficiently and consistently, enhancing customer satisfaction by having a detailed overview of all configuration items and their interrelations.
• Enhanced incident and problem management
  • With a complete CMDB, support teams can quickly identify affected services and assets during an incident, leading to faster resolution times and reduced downtime.
• Effective change management
  • Understanding the dependencies between CIs allows for better planning and risk assessment of changes, thus minimizing the impact on service delivery and avoiding potential disruptions.
• Strategic decision-making support
  • The CM process provides valuable insights into the IT infrastructure, aiding in strategic planning, budgeting, and investment decisions by providing a clear picture of the IT environment and its needs.
• Regulatory compliance and risk reduction
  • A well-maintained CMDB helps ensure that the organization meets regulatory compliance requirements by providing clear documentation and history of IT assets and their configurations, thus mitigating risks associated with non-compliance and data inaccuracies.

Actors and Roles