Six configuration management database pitfalls to avoid

How to significantly increase the likelihood of a successful configuration management database implementation.
Written by Randal Locke, Contributor
IT shops implementing Configuration Management Databases (CMDBs) should take precautions to ensure project success, prevent unnecessary project delays, and speed time-to-value.

This article focuses on six of the most common pitfalls to avoid when implementing a CMDB. By avoiding these pitfalls, an organization can significantly increase the likelihood of a successful CMDB implementation.

Pitfall 1: Failing to identify the goals and benefits
A CMDB manages items and relationships in your environment that are critical to your business services. These items can be services, software, hardware, systems, operating systems, applications, databases, functional roles, process documents, security documents, network components and more. The importance of given items and relationships varies from one organization to the next, but the CMDB cannot, and should not, manage every asset, document, or process throughout your entire enterprise. In this broad landscape, do not lose sight of the specific goals and benefits that apply to your own organization.

If you know how a CMDB can be used, such as understanding the impact of change, you can conduct a cost-benefit analysis that measures project objectives against the cost of CMDB purchase and implementation. Having clearly defined short-term goals and long-term plans is critical to the initial stages of a CMDB project. If you fail to properly define the goals and quantify ROI, you may have difficulty gaining management approval.

Pitfall 2: Turning your CMDB into a metadata dumping ground
There is a difference between what can be managed in a CMDB and what should be managed in a CMDB in order to derive maximum business value. Organizations sometimes initiate their CMDB implementations by indiscriminately dumping all the data from all of their configuration item (CI) repositories into their CMDB, without adequately documenting relationships or managing change for the CIs.

Your CMDB should contain only those CIs that you plan to actively manage. If you dump data into the CMDB without a plan, you will quickly find yourself with a repository that is hard to manage and provides little value.

When CIs are actively managed, you can perform impact analysis to understand the risks associated with current outages and pending changes in the environment. This is a crucial step in realizing value from your CMDB initiative.

Pitfall 3: Ignoring the need for effective change management
Without an effective change management process, a CMDB will soon be out of sync with reality. Thus, the CMDB and Configuration Management processes must be tightly aligned to the Change management process. Only authorized changes should be incorporated into the CMDB, and only CIs that are part of a Request for Change (RFC) should be updated. Avoiding this requirement will place the CMDB implementation on a downward spiral to failure.

Pitfall 4: Proceeding without buy-in from key stakeholders
By their nature, CMDB implementations have a wide range of touch points within an organization. Financial, capacity and availability attributes of CIs all require input from separate departments. If key stakeholders are not involved from the beginning, and if they don't buy in to the true value that a CMDB can deliver to the organization, it will be very difficult to get them to assist in the building of a CMDB that contains all necessary attributes and relationships.

Therefore, it is critical to secure the support of key stakeholders at the beginning of your CMDB initiative. By demonstrating that the CMDB will enable stakeholders to continually improve their relevant metrics and key performance indicators (KPIs), you will be able to achieve the requisite buy-in from all appropriate parties. In gaining this support you must ensure that these stakeholders understand that controlling these CIs in the infrastructure will lead to a decrease in incidents within the environment as well as a significantly improved change process.

Pitfall 5: Attempting too broad an implementation
Starting out with a controlled pilot project, such as the implementation of a single clearly defined business service, is key. Determine the CIs that support that business service first, such as the application servers, Web servers, routers, databases and database servers. Next, determine what types of relationships exist between these CIs, such as "runs on", "hosts", "connects to", "relies on", "fails over to", or "manages". These relationships improve understanding and mitigate the risk associated with changes to any of the CIs that make up the service.

Once the CMDB is successfully implemented with this first service, you and your organization can make decisions on extending the scope of the initiative and managing more CIs in an effective and efficient manner. This incremental approach allows your organization to realize value quickly, while gaining the experience needed to successfully tackle a broader implementation.

Pitfall 6: Skimping on process and training
A CMDB is only as good as the people who use and maintain it. If people aren't trained in proper use and maintenance procedures the CMDB will be under-utilized and the contents will quickly become out-of-date and inaccurate. Proper training also helps to ensure a successful implementation and a well-spent investment.

Organizations that avoid these six pitfalls will safeguard their CMDB implementations and improve the likelihood of successful outcomes. Ultimately, that means that they will be better able to cost-effectively provide the business with the services it needs while keeping those services running at required levels of performance.

Randal Locke is a senior technical specialist at CA.

Editorial standards