Configuration Management Databases (CMDBs) have been presented as a foundational utility enabling IT Infrastructure Library (ITIL) based management practices. Once implemented, CMDBs result in many significant benefits to change, asset, and service impact management.
In recent years, CMDBs have received some bad press from detractors due to the many CMDB projects that have failed to deliver a positive ROI. These outcomes shouldn’t imply that CMDBs are a bad idea in general. Instead, they highlight the importance of planning, implementation, and realistic expectations.
What is a CMDB? How is a Configuration Management Database Used?
First of all, what is a CMDB? A CMDB stores devices, components, and other entities of IT infrastructure as Configuration Items (CI), and can include extensive data on each. It also stores how different CIs relate to each other in various application or business service contexts.
So, why is a CMDB useful? Having CIs along with their attributes and relationships in one place:
- Eliminates each application having to redundantly discover and store configuration, relationship, and access information for the same CI
- Avoids discovery or configuration mismatches and inconsistencies
- Enables administrators to manage configurations in one place
- Reconciles multiple aliases to refer to the same CI, avoiding the confusion of having multiple CIs exist for the same entity
To illustrate the complexity of resolving different references to the same CI, take some of the numerous ways applications can refer to the same Oracle database:
- Oracle Database name = Ora_Ecomm
- Oracle Server ID (SID) = Ora_123
- Oracle Server connection “listeners” host and port = EcommSvr:86
- Oracle Server connection “listeners” ip and port = 198.192.4.23:86
- Oracle connection TNS names = EcomrcMainDB, EcomrcSalesDB, & EcomrcInventoryDB
Discovery, monitoring, and integration tools should be able to look up a CI within a CMDB using any of the various aliases. For a monitoring application, this is the difference between understanding that one database exists and not seven.
These benefits illustrate why the CMDB is often referred to as the “single source of truth.”
CMDB Pitfalls
Now that we understand the benefits of a CMDB, what are some of the pitfalls that can lead to problematic deployments and a limited or negative ROI? The difference between success and failure often comes down to two key factors:
● To store, or not to store, that is the question: The most important decision is what to put into and, more importantly, not put into the CMDB. The natural first inclination is to register everything and anything into the CMDB. However, using the CMDB as a dumping ground for information ultimately dooms its projects to failure. It results in massive amounts of irrelevant data that cause response times for CMDB applications to slow down due to long query times and too much information returned for applications to filter through efficiently.
Before you start populating data into a CMDB, determine the appropriate information model to build into it. An appropriate information model must be able to answer business questions and solve business problems. Auto-populating CMDBs with discovery data alone isn’t sufficient.
● Treat the CMDB as a “process” or journey; not as a data warehouse to set up once and forget. CMDBs won’t provide value on their own. Adjust your operational processes to properly leverage the CMDB and maintain quality information because CMDBs won’t cleanse data for you. Another mistake is not identifying and (over time) adjusting the information that needs to be populated into the CMDB to restrict what is stored to only the information necessary to answer business questions and the problems at hand.
Key CMDB Best Practices for Success
Implementing and using CMDBs is a complex process and often unique to each company. Providing an exhaustive, detailed analysis is beyond the scope of this article, but here are a few basic recommendations:
● Carefully restrict the scope of the CMDB project. Avoid boiling the ocean by trying to model and populate every device and application. Instead, start by picking a particular problem domain to pinpoint the relevant business questions and identify the key services, applications, and devices involved.
● Attack additional domains one at a time. By taking an incremental, or staged, approach with your CMDB you (and your management team) will be able to see a steady cadence of successes over time.
● Share CI identification information between tools. For example, this might include sending an event to the Zenoss unified monitoring platform or having Zenoss open a ticket in the incident manager. Sharing the CI data in communications allows and ensures all tools involved in information handshakes are referencing the same entity.
● Identify a single tool to discover and populate information into the CMDB. It is recommended to have a single mechanism that “owns” creation of CIs in the CMDB. Having multiple tools populating the CMDB can lead to significant complexity in order to avoid redundant and inconsistent population of CI and related information. Many customers use Zenoss to directly populate monitored entities into the CMDB. You can also have tools such as ServiceNow populate the CMDB, while Zenoss looks up the CIs and relates them to the devices and components being monitored.
● Determine a strategy to identify, populate, and maintain CMDB information.
Generally there are three approaches for populating a CMDB:
1. Infrastructure-based approach
This approach requires creating an IT asset inventory. It is typically executed by various organization silos (e.g. register databases by DBAs). Unfortunately, the approach usually provides minimal relationship details between CIs and little or no application or service context.
2. Application-based approach
This is the more typical approach taken by IT organizations and is where auto-discovery utilities usually fit in. It provides relationship information at the application level based on what the discovery utilities can identify, however it provides little service context. The auto-discovery utilities try to discover as much of the environment as possible which, in turn, can lead to the largest cause of CMDB problems (overpopulation).
3. Service-based approach
This approach involves focusing on your key service and business questions to identify which data to populate to ensure efficient and effective CMDB use. Historically, the service-based approach was only used by mature IT organizations because it required prior detailed administrator knowledge of service and infrastructure interdependencies. Additionally, this approach was less commonly used due to its complexity. Fortunately, Zenoss Service Impact eliminates much of that complexity because it automatically discovers and maintains the infrastructure interdependencies within a service model, which is critically important in highly dynamic environments.
The service-based approach is usually recommended for Zenoss customers. It achieves a better business value ROI without the complexity of manually identifying infrastructure dependencies because Zenoss Service Dynamics provides it automatically.
Zenoss CMDB Integration Package
The Zenoss CMDB Integration Package enables Zenoss to either leverage or auto-populate CMDB contents, benefitting both Zenoss operations and other CMDB-integrated applications and workflows. Zenoss can be configured to improve CMDB accuracy by supplementing it with real-time information and newly discovered IT resources. If instead you want to use other tools or approaches to populate the CMDB, you can configure the integration package to automatically detect both new and modified entities in the CMDB to monitor. Both configuration options provide:
● Reduced coordination amongst teams. For example, if one team adds a new server and forgets to notify operations, it will still be detected and monitored.
● Highly dynamic environments, such as VMs frequently being VMotioned to other devices, can leverage Zenoss’ immediate detection so that other applications are working with current information and not referencing the results of yesterday’s auto-discovery tool.
● Zenoss alert notifications or incident manager integrations (such as ServiceNow or BMC via the Zenoss Incident Management Integration Package) may be augmented with CI information to enable more intelligent and consistent automated workflows.
Partner With Zenoss for CMDB Strategies 
Implementing a CMDB is a complex undertaking involving the coordination of multiple teams, resources, and applications. This article has highlighted recommendations which, based on Zenoss’ experiencing working with several organizations, are critical to CMDB project success (the references section below includes additional resources).
Zenoss Professional Services can provide analysis and guidance on how to best integrate Zenoss with a CMDB as well as other tools which will utilize the CMDB, such as incident management applications like ServiceNow and BMC Remedy.
References
● Zenoss Integration Packages
● The secret to a successful CMDB, Brad Serbu
● An Effective Configuration Management Database May Be More Attainable than You Think, Marty Likier
● Are You Implementing a CMDB or a Process?, Gary Case
● CMDB/CMS Use Cases: Service Impact Management, Dennis Drogseth
