CMDB Essentials: 8 Elements for the Modern IT Support Operation

As IT environments evolve and expand in size and complexity, IT and Network Operations teams face a formidable challenge: managing a growing number of assets, services, and interdependencies in real time.

Each delay or error in bringing incidents to resolution can lead to costly downtime and dissatisfied customers. And these challenges only get more fraught when data is fragmented and siloed. In many organizations, different teams handle various aspects of the IT infrastructure, each employing its own tools and systems. This disconnect results in inconsistent and outdated information.

Having spent the last 23+ years delivering network operations center (NOC) services to teams through the enterprise, service provider, and OEM spaces, we’ve witnessed how damaging this disjointed approach can be to a business.

A robust configuration management database (CMDB) brings order to this chaos: a central repository designed to consolidate and streamline information about IT assets and services, offering a unified and comprehensive view of the entire IT landscape.

In this guide, we briefly explain the significance of a CMDB in the modern NOC (or IT support operation more generally), the CMDB challenges teams typically face, and the eight crucial building blocks that constitute our own CMDB—the single source of truth that sits at the center of our support platform and empowers us to deliver high-quality 24x7 NOC support services at scale.

What is the Purpose of a Support-Focused CMDB?

The primary objective of a CMDB is to provide information that empowers better business decision-making and streamlines processes. By centralizing all configuration data, teams can better understand critical configuration items (CIs) and their interconnections. This knowledge is indispensable for modern impact analysis, root cause analysis, and incident and change management.

In today’s NOC, the CMDB is the foundation for efficient and effective infrastructure management. It equips NOC teams with a holistic view of the entire IT infrastructure, encompassing assets, relationships, dependencies, and service offerings. This comprehensive insight is vital for identifying and addressing potential issues, prioritizing incidents, optimizing resource allocation, and operating at scale across numerous support customers.

The CMDB is also critical for enhancing communication and collaboration among various teams within the organization. Dismantling information silos and offering a single source of truth ensures that all stakeholders can access precise and current data, crucial for informed decision-making and synchronized response to incidents or changes.

Given the size and pace of change in today’s IT environments, the importance of a CMDB in the NOC really can’t be understated.

In short, putting a robust CMDB at the heart of the NOC ensures the team has an accurate, up-to-date inventory of all IT assets and how they relate to one another. This, in turn, allows for a faster and more effective response to incidents while minimizing the impact of any changes made to the IT environment. 

What CMDB Challenges Do Teams Typically Encounter? 

In a 2019 report, Gartner found that only 25% of organizations that invest in a CMDB feel they get meaningful value. Given the lift required to set one up and maintain it, it's common for organizations to get frustrated with their database investments.

In our experience, a few common CMDB challenges undermine the value of what should be a critically important ITOps component.

The first challenge is an uneven commitment within an organization. The ITOps team may be entirely motivated to use and maintain the CMDB to manage their CIs. Still, other departments may not see the value or want to devote the necessary resources to maintaining it.

• At INOC, our supported customers rest assured that their CMDB is managed consistently and effectively without requiring additional resources or commitment from other departments. They essentially outsource this challenge away.

CMDBs also suffer when their purpose isn’t clear or specific. It’s possible to take the idea of a “single source of truth” too far. Teams sometimes need to consider its actual use cases to centralize their data. A CMDB should be a single source of truth—that is, for purposeful, valuable data that supports internal processes such as change management. Too many CMDBs, however, don’t have a well-defined objective, designated owner, or mechanism to update data to reflect any changes. Not having a focused intent or purpose for the CMDBs surely leads to a database that’s difficult to navigate, less trustworthy, and ultimately less useful.

• We’ve refined our CMDB to support NOC processes such as change, incident, and problem management. We work with each customer to ensure that it focuses on providing purposeful and valuable data.

Poorly executed data centralization is another common problem. A CMDB's purpose is to provide a centralized view of asset data, but teams should only store some asset data in a single database. The best practice is to federate data from other tools and systems to support each use case. The CMDB can still import and reflect this data, even if it is not the primary storage location. 

• Our CMDB isn’t a single database but an integrated platform of tools and data sources. This approach ensures that data is stored in the most appropriate location while still providing a centralized view of that data.

Data/coverage inaccuracy is another big challenge. Failing to run discovery tools or audits frequently, lacking automation rules, and relying on manual inputs are some of the most common issues resulting in an inaccurate CMDB. When an organization relies on flawed methods to maintain its database, keeping up with the constantly evolving IT environment becomes challenging. As a result, the CMDB can quickly become outdated and even misleading. The best CMDBs combine traditional bottom-up discovery (mapping infrastructure and expanding discovery to include customer-facing CIs) with event-driven discovery (triggered by a system event that prompts the system to map related CIs and their connections.)

• We frequently run discovery tools and audits to ensure that each customer’s CMDB accurately reflects the constantly evolving IT environment.

What Components Comprise a Gold-Standard NOC CMDB in 2024?

Below, we’ve deconstructed our own CMDB to present it as a model for the NOC and broader IT support function. Under each component, we’ve included a few questions for self-assessment that can help reveal the value of a service like INOC’s when powered with a sufficiently robust CMDB.

1. Knowledge Articles

• The main point: Knowledge articles in the CMDB improve service delivery by providing accurate, up-to-date information to NOC engineers, allowing them to work faster and more efficiently. These resources also help establish trust between customers and the organization by standardizing processes and promoting confidence.
  
  

Knowledge articles are an essential component of a NOC CMDB that enables efficient and effective incident handling. They guide NOC engineers to address common and specific issues, promoting faster resolution times and improved customer satisfaction. A practical knowledge article documents best practices so the team can scale those practices from one person across an entire team.

While the shape and content of a knowledge article depend entirely on the support team using it, we’ve found a few general qualities that make these resources effective.

The first is relevance. A strong knowledge article should address common issues or processes that NOC engineers regularly encounter, ensuring that it applies to most situations and clients.

Knowledge articles should also be clear and well-structured. Their contents should be easy to understand, with clear and concise language, step-by-step instructions, and well-defined procedures. Knowledge articles should also follow a consistent, thoughtful structure, with headings, subheadings, and bullet points, to make it easy for the support engineers to quickly find and follow the necessary steps.

Other essential elements include:

• Accuracy — IT infrastructures constantly change, so knowledge articles should, too. Information should be accurate, up-to-date, and validated by experts or subject matter experts to ensure that the guidance provided is reliable and trustworthy. Processes should be in place to regularly review and update knowledge articles to ensure they remain current, accurate, and in line with best practices or changes in technology, processes, or client requirements.
• Accessibility — Knowledge articles should also be easily accessible within the CMDB, enabling engineers to quickly find the information they need without searching multiple documents or databases.
• Visual Aids — Where applicable, knowledge articles should include diagrams, screenshots, or flowcharts to illustrate complex concepts or processes more effectively, making it easier for the engineers to follow the instructions.

📄 Read our other guide—The Anatomy of an Effective NOC Runbook—for a related discussion on proper documentation in the NOC.

With knowledge articles, two best practices are important to acknowledge:

A. Follow the 80/20 rule

At INOC, we focus on developing articles that cover approximately 80% of the situations our NOC engineers expect to encounter regularly. These articles should be “usefully generic” and applicable to most customers or end-users rather than focusing on specific cases or networks.

For example, a knowledge article on handling a fiber cut should provide a general process that applies to all or most customers instead of being tailored to specific spans, states, or networks.

B. Document edge cases

While “general” knowledge articles are essential, it's also vital to document edge cases for unique or irregular procedures.

These technical articles ensure that NOC engineers have clear instructions for responding to scenarios that demand particular or non-standard actions, such as sending notifications for unique customer requirements.

Striking a balance between general and particular knowledge articles is essential to avoid overwhelming the NOC with too many narrowly focused articles while providing sufficiently clear and actionable direction.

Knowledge articles within the CMDB translate into better service for clients in three observable ways:

• Faster Service Delivery — Having the necessary information in knowledge articles enables the NOC to work faster and more effectively, reducing the need to contact customers for further information or spend time digging.
• Removing Inefficiencies — Knowledge articles also help eliminate subjectivity and ensure that support engineers follow a standardized process no matter who picks up a ticket or interfaces with an incident. This results in increased efficiency and reduces the likelihood of choosing the wrong course of action, which can lead to delays and customer dissatisfaction.
• Promoting Confidence and Establishing Trust — By providing transparent processes and guidance, knowledge articles enable NOC engineers to demonstrate their expertise in handling various issues, building trust and confidence in customers, and reflecting well upon the entire organization.

2. Third-Party Contact Data

• The main point: Having accurate and well-organized contact data for third-party vendors, service providers, and other stakeholders in the CMDB streamlines communication and collaboration. This leads to faster issue resolution and improved customer satisfaction.
  
  

Third-party contact data includes contact information for vendors, service providers, and other external organizations that may be involved in ITOps. This data typically pertains to carrier data providers, customer data for end-users of client services, and vendor support.

Integrating this information into the CMDB serves multiple purposes (explained below) and ensures that the necessary details are readily available to NOC engineers when needed.

Each type of third-party contact data serves a specific purpose within the CMDB:

• Vendor Support — Having the contact information for technical support centers associated with asset records enables NOC engineers to open cases quickly without searching through external documents or databases. Contact information can include phone numbers, email addresses, and support portal URLs associated with various hardware or software vendors involved in a client's infrastructure.
• Customer Data — This information lets engineers know whom they're speaking with, their contact details, and any relevant identification numbers to ensure smooth communication. (We break out customer data as its own component of the CMDB later in this guide.)
• Carrier Data — Access to carrier information ensures that engineers can effectively communicate with carriers by providing the necessary identification and addressing details. This can include phone numbers, email addresses, account or circuit identification numbers, etc.

The importance of accurate data representation

The key to the effective use of third-party contact data is the type of data captured and how it is represented within the CMDB. Correctly categorizing and identifying contacts helps the NOC understand the scope of responsibility and appropriate actions.

Some distinctions we consider when capturing third-party contact data include:

• Field Technicians vs. Carriers — Field technicians and carriers have different responsibilities, so it's essential to differentiate between them in the support context to avoid not particularly useful conversations or requests.
• Customers vs. Venues — While customers may be responsible for the service, venues may be accountable for an entire area or entity, including physical hardware. Distinguishing between these two ensures engineers know whom to contact for specific issues.
• Vendor Technicians — Accurately identifying vendor technicians helps avoid confusion and ensures that engineers communicate with the right contact for the task.

3. Circuit Data

• The main point: Comprehensive and accurate circuit data within the CMDB enables NOC engineers and machine learning systems to identify and address network issues quickly. By documenting circuit ownership, demarcation data, carrier IDs, and addresses, a NOC can efficiently restore services and minimize downtime.
  
  

Circuit data includes information about network circuits, including their physical location, bandwidth, and other details. Circuit data is an essential component of a NOC CMDB, as it represents the physical connections between different points in a network.

The following elements are crucial when it comes to integrating circuit data in a CMDB:

• Near and Far Ends — Ensuring that both ends of a circuit (near and far) are captured and documented within the CMDB allows NOC engineers to establish the specific link and determine which components may be impacted during an outage or incident.
• Demarcation Data — This includes information about patch panels, which are responsible for connecting different components in the network. Properly documenting patch panel data is crucial for technicians to identify the correct paths and restore services efficiently.
• Circuit Ownership — Documenting the owner of the physical connections (such as cables or fiber) helps staff determine who is responsible for maintaining the circuit and who to contact in case of issues.
• Carrier IDs and Account Numbers — Accurate carrier IDs and account numbers are critical for opening tickets and requesting support from service providers. Inaccurate or missing carrier IDs can lead to prolonged outages or provider miscommunications.
• Addresses — Recording the addresses associated with each circuit component helps engineers quickly identify the exact locations of potential issues, allowing for faster resolution times.
  

4. Customer Data

• The main point: Accurate customer data allows NOC engineers to communicate effectively with affected individuals during outages or service disruptions. By understanding each customer's specific services and aligning terminology, support teams can prioritize their efforts and ensure clear communication, ultimately leading to faster issue resolution and enhanced customer satisfaction.
  
  

Customer data is a vital component of a NOC CMDB as it enables engineers to identify and communicate with the individuals affected by outages or service disruptions. Accurate and up-to-date customer data helps ensure that support teams can quickly and effectively assist with incidents.

Key elements of customer data include:

• Contact Information — Accurate and up-to-date contact information for customers, including names, phone numbers, and email addresses, enables the NOC to notify customers of any service disruptions or outages and receive notifications from customers regarding potential issues that may not have triggered alarms.
• Service Details — To effectively assist customers, NOC engineers need to understand the specific services each customer depends on. Knowing the details of each customer's services allows support teams to prioritize their efforts and address the most critical issues first
• Client-Customer Terminology Alignment — It’s vital to align the terminology clients and customers use when describing services and components. This alignment helps ensure clear communication and understanding when discussing issues or troubleshooting problems, reducing the potential for miscommunication or confusion.

5. Alarm Data

• The main point: Properly managed alarm data allows for seamless automation processes, such as customer notifications, incident prioritization, and alarm correlation patterns. Accurate alarm data ensures incident management processes run smoothly, with correct ticket prioritization and prompt customer notifications.
  
  

Alarm data includes information about alarms and alerts generated by IT systems, including their severity and impact.

At INOC, alarm data is crucial for the automation processes within our CMDB and the broader support platform. While we don’t store it as CMDB data, alarm data must match the corresponding CMDB data to ensure seamless integration and efficient handling of incidents.

Here are a few ways alarm data is critical in our NOC operation:

• Automation — Alarm data is the foundation of various automation processes within our NOC, including customer notification, incident prioritization, and correlation patterns from an alarming perspective. Accurate alarm data ensures these processes run smoothly and efficiently, helping to identify and resolve issues promptly.
• CI Matching and Ticket Creation — When alarms are generated, they must match the corresponding CIs in the CMDB. For example, alarms enter our AIOps engine, which then pushes them into our ITSM system (bespoke ServiceNow), creating an incident ticket. ServiceNow runs an escalation that matches the alarm to a hostname or a specific field. If the alarm data does not match the CI, the automation processes will break, resulting in the "misprioritization" of tickets, failure to notify customers, and other issues.
• Incident Management — Properly matching alarm data with the CMDB ensures that our incident management process runs smoothly and efficiently. Once the CI is attached to a ticket, it’s prioritized, and customer notifications are sent automatically. If the CI-attaching mechanisms don't match, tickets can’t be accurately prioritized, and customers can’t be notified. This may result in a high-priority ticket being mistakenly classified as a low-priority ticket, causing delays in resolving the issue.
• Impact on Customer Experience — Misaligned alarm data can lead to a breakdown in communication between the NOC and its customers. If customers aren’t notified of an issue, they may call to inquire about it, leading to further delays in resolving it as the NOC creates new tickets to investigate the problem.

6. Location Data

• The main point: Location data helps engineers quickly identify and address issues by pinpointing the physical location of IT assets. This information also assists in determining the impact of potential problems on the network and planning for maintenance or upgrades.
  
  

Location data includes the physical locations of IT assets, such as servers, switches, and other infrastructure components. Location data plays a crucial role in our  CMDB by providing information about the physical location of the CIs. This information includes the name of the site and its exact coordinates, which help identify and resolve issues with specific assets.

This location data not only helps identify where a CI resides, such as circuit IDs but also offers insights into the physical components of a network. These components can include hosts, switches, firewalls, routers, and other hardware devices that contribute to the overall functioning of a network.

In some cases, location data may be generalized to accommodate instance-based environments, but for the most part, it should refer to the physical location of an asset.

7. Asset Data

• The main point: Comprehensive and up-to-date asset data helps NOC engineers understand the network's structure and connections between various components. This gives engineers a more comprehensive understanding of the network and its elements by connecting asset data to other types of data in the CMDB, such as circuits, services, and interfaces. 

Asset data includes make and model, serial numbers, and other asset-specific details. Asset data forms the foundation of our CMDB as it encompasses the physical components of a network (or virtual in some cases), including hosts, switches, firewalls, routers, and other hardware devices. These assets are critical to the functioning of the network and are the source of alarms that indicate potential issues or service degradation.

In the CMDB, asset data helps identify the physical or virtual devices being monitored and provides essential information, such as the type of device, the vendor, the platform, and the model. These details enable the NOC to understand the network's structure and the connections between various components.

A key aspect of asset data is its relationship with other data types in the CMDB, such as circuits, services, and interfaces. These data types must be connected to an asset, signifying their dependence on a physical or virtual device. This connection is vital for a comprehensive understanding of the network and its various elements.

In some cases, asset data may be generalized for instance-based environments. Whatever form it is, for the most part, asset data focuses on the devices that can trigger alarms and require monitoring. Accurate and up-to-date asset data is critical for teams to manage and maintain a network's performance effectively.

8. Service Data

• The main point: Well-organized service data enables NOC engineers to understand the impact of alarms on customer-facing services and prioritize incident resolution accordingly. This distinction between connectivity and customer offerings is significant in cloud services. A structured and integrated approach to service data in the CMDB can help assess and address customer-related incidents more effectively, leading to higher customer satisfaction.

Service data in our CMDB refers to the various services customers utilize that cross the network. These services often use circuits as a means of transportation and are the offerings customers pay for, such as email, internet access, or TLS links. Service data captures information about these customer-facing elements and helps the NOC understand the impact of alarms on these services.

The concept of service data has evolved. Today, it’s become more predominant than its circuit counterpart, especially in cloud services. Previously, these services were modeled as circuits, but the shift towards modeling them as application services have clarified the distinction between physical connectivity and customer offerings.

When an issue arises, such as a down port, understanding the affected services is crucial for the NOC to assess the impact on customers and prioritize incident resolution accordingly.

A Brief Overview of INOC’s CMDB

The INOC CMDB is the service intelligence that powers our NOC support service, operational workflows, and platform automation. Its makeup extends well beyond the primary asset or device data that comprises many CMDBs—containing all of the essential information needed by our AIOps tools to:

• Correlate the event stream at machine speed.
• Raise the appropriate incident ticket.
• Assess the impact of an incident.
• Guide the NOC through the management of its resolution.

That's why high-quality CMDB data is a major onboarding focus and why it's essential to have rigorous change processes to maintain the CMDB with our clients through the service lifecycle. The service simply cannot function without it.

A seamless CMDB integration with each of our supported customers ensures our configurations are a perfect match. For each alarm we receive and each subsequent ticket we create, a CMDB integration associates the appropriate meta information, arming our NOC engineers with the actionable knowledge they need to make informed decisions.

When necessary, we also draw on years of experience to enhance existing CMDB structures and capabilities, further improving efficiency and effectiveness.

During our discovery workshops with teams interested in NOC support, we review existing CMDB sample data points and how our robust CMDB can provide value beyond NOC support. Contact us to learn more and schedule a discovery session.

A General CMDB Checklist for Self-Assessment

Here’s a brief checklist of questions to assess the strength of your CMDB and articulate the need for third-party support. Contact us to explore solutions in these areas in greater depth.

• CI audits and data quality maintenance — Do you have processes to audit and maintain the data quality within your CMDB regularly? Are you actively updating and validating the information, such as contact details, to ensure efficient communication in case of failures or incidents?
• Visibility into CI metrics and analytics — Do you report on CI metrics and analytics to track the health of your CIs, their relationships, the impact of changes, and patterns that lead to incidents or problems?
• Methods for creating CIs and populating data — Can you create CIs via manual input, integrations (API-driven, SCCM), and discovery tools that scan the network to collect software and hardware info to gather an inventory of each physical and virtual device?
• Compliance features — Do you have compliance features that provide detailed records and visibility for auditors into the current state of CIs and their historical changes, checks, balances, incidents, etc.?
• IT service mapping — Does the CMDB include IT service mapping (often a graphical illustration of relationships and dependencies)?
• Access controls/change tracking — Can you grant different access levels to other people or teams as needed and trace changes back to their source in case of questions or incidents?

Final Thoughts and Next Steps

In today’s rapidly evolving IT landscape, the importance of a comprehensive, up-to-date CMDB cannot be overstated. By consolidating and streamlining information about IT assets, services, and interdependencies, a well-maintained CMDB serves as a single source of truth that equips Network Operations teams with the information and insights necessary to manage complex IT environments efficiently.

Simply put, a robust CMDB empowers organizations to make better-informed decisions, streamline their processes, and improve incident, problem, and change management, ultimately minimizing costly downtime and maximizing customer satisfaction.

With 23+ years of experience in delivering exceptional NOC services, we understand your business's challenges and are here to help you streamline processes and enhance decision-making.

Get in touch with us to explore the various NOC service options tailored to suit your business needs. Our Solutions Engineers will show you how our gold-standard CMDB and broader support platform can drive more efficient incident and problem management, achieve seamless change management, and optimize resource allocation.