If you have any experience with a configuration management database (CMDB), you’ll likely agree with this statement: The usefulness of a CMDB is often limited by its inherent complexity.
While most CMDB issues historically have been people and process related, the complexity of the technology hasn’t helped. In fact, according to a recent Gartner publication, Implement IT Change and Configuration Management Before Developing a CMDB, “More than half of CMDB efforts become unmanageable, due to a lack of business alignment, inappropriate scope, or inadequate process rigor.”
But that doesn’t have to be true. And it shouldn’t be true.
How Easy Is Your CMDB?
A CMDB, of course, is a configuration item repository that serves IT operations management functions. CMDBs contain data relative to the assets and their relationships that support the services delivered by IT. The purpose of a CMDB is to provide asset, state, and dependency information to ensure effective IT Service Management (ITSM) processes. And, this same information and associated processes support audit- and compliance-related activities.
But as noted above, it doesn’t always work out that way. The more common scenario is that the CMDB itself turns into a black hole of data. Instead of easing IT administrative burdens, it compounds them.
How do you know whether your CMDB is problematic?
If your CMDB requires dedicated specialists to manage it, that’s a clear indication that your CMDB might be hurting more than helping—or, at least, not helping as much as it should.
If that’s the situation you’re in with your CMDB, some changes are needed. Ensuring your CMDB offers the following four important features will help transition your CMDB from a hindrance to a help.
Tweet this: Ensuring your CMDB offers these four features will transform it from a hindrance to a help
1. Easy Input of Data from Multiple Sources
Making a CMDB useful requires frequently loading it with a variety of disparate data from multiple sources. Often there’s an over-reliance upon human data entry or batch loads, which frequently suffer from configuration drift and then out-of-date or inaccurate data. Manual creation of relationship or dependency information is especially problematic and hard to maintain.
Common sources of CMDB information include asset discovery and management tools such as Microsoft System Center Configuration Manager (SCCM), Symantec Altiris™, or Dell KACE™. Other operations management tools are also common information sources that can have CMDB integrations. Adding new or custom integrations to input data should be a relatively quick and easy process: think hours or days instead of weeks or months. A specialist should not be required.
Automated discovery is also very helpful in keeping the data stored in the CMDB accurate and up-to-date. However, this is more the responsibility of the discovery processes and less a feature of the CMDB itself.
2. Easy Support of Multiple Consumers of Configuration Item Information
A CMDB should be able to support a diverse consumer base of Configuration Item (CI) information—and that applies to users both inside and outside of the IT department. For the service desk staff, the CMDB commonly supports Incident and Problem Management root cause identification. The CMDB supports Change Management impact analysis and unplanned change detection. The CMDB also supports standalone configuration management use cases such as data center moves, consolidation, and disaster recovery.
Within the extended IT organization, users also represent a fairly diverse group, including Asset Management, Security, IT Performance and Availability Monitoring, and Compliance. A CMDB can be used outside of IT for departments such as facilities, which can track heating, ventilation, and air conditioning (HVAC) equipment as CI’s. A Fleet application can use a CMDB to track trucks and trailers as higher level CI’s supported by tires, wipers, and even oil changes as supporting CI’s.
3. Easy Application Dependency Mapping (ADM)
CMDBs store relationship information in addition to CI’s; however, establishing and maintaining these relationships is often challenging. Extending relationships to the generations of service models based on CI relationship information can be a complex, manual, and time-consuming task.
The ability to easily generate application dependency maps is crucial for supporting change management and other ITSM processes. A CMDB should help to:
- Improve the change management process by providing impact analysis and reducing the number of self-inflicted service outages resulting from change collisions
- Improve incident and problem management by facilitating faster root cause identification
- Improve visibility into everything that’s involved with providing a service or supporting an application
Application dependency mapping facilitated by your CMDB can also help to substantially improve security. For example, ADM helps security teams more accurately understand the environment they are charged with protecting. It also helps with cataloging service entry points for the purpose of revealing those that require greater hardening to withstand exposure to external networks. Finally, ADM provides a better understanding of normal connectivity, making it easier to identify rogue systems or traffic.
Tweet this: Application Dependency Mapping helps security teams more accurately understand the environment they are protecting
4. Easy Support of Dynamic Environments
In the past, IT infrastructures, applications, and CMDBs were relatively static, and management could rely on discovery updates to keep information current. It was common, in fact, for all of the configuration items managed by the CMDB to be owned by the organization and kept on site.
But operating environments have changed substantially in recent years. CMDBs must now regularly support more dynamic environments, such as public clouds, private clouds, and hybrid clouds—not to mention traditional environments.
Furthermore, the advent of DevOps and continuous deployment, with higher application change and release velocities, makes configuration management more difficult, and simultaneously, more important. In a DevOps environment, with multiple IT teams operating at radically different speeds, knowledge disconnects and communication issues are likely to occur with increased frequency.
A CMDB should support event-driven updates and automated changes in addition to discovery or manual-based mechanisms. The CMDB should also easily support the assignment of CI’s that are under configuration and/or change management. In increasingly dynamic environments, the degree of control over configuration management can vary greatly depending on criticality, audit controls, and compliance risk, in addition to the release velocity.
Routine management and oversight of a CMDB should not be an ordeal. Nor should the services of specialists be required in managing or interacting with the CMDB. No special training should be needed, and no additional administrative burdens should be incurred.
Ultimately, a CMDB should be a flexible system that can facilitate many integrations. It should grow with you, be easy to maintain, and easy to keep up-to-date. Visualization of CMDB data should be easily accomplished through the use of service models, reports, and dashboards, without the need for additional skill sets.
If your CMDB provides each of the “easy” must-have features from the above list, then you’re likely enjoying the many benefits that CMDBs should offer. If not, it may be time for you to contemplate a change in systems and your approach.
Next Up: Explore Cherwell’s CMDB Software
Discover how you can improve impact, risk, and root-case analysis with Cherwell