Start Building Your CMDB

Where should you start when building your CMDB?

Many consultants and vendors suggest purchasing a tool before beginning the building of the CMDB.However, this is unnecessary since most IT organizations have very little idea, from the outset, about exactly what type of information will eventually wind up in the database(s).

To start, an Excel spreadsheet will work fine. The idea is to begin by mapping out the entire Configuration Management process prior to the purchase of a fancy, and expensive tool. Often one of the biggest dilemmas associated with building the CMDB is deciding where to begin.

It is considered good practice to involve other process owners in the design of the CMDB. This way, you can ensure that the database contains information that will be immediately useful and beneficial to the organization. This also helps in getting started.

Most organizations usually already have some form of Incident and Change Management processes in place. These processes are sometimes referred to as the “customers” of the Configuration Management process.

In this sense, Incident and Change Management will benefit directly from the data to be stored in the CMDB. Starting with the requirements from these two processes is also an effective way to resolve the often lengthy discussions regarding the CMDB strategy and design.

For example, the Change Management process uses relationship data from the CMDB to help in determining the potential impact and/or risk, to IT service availability, associated with changing a particular Configuration Item (CI). This is helpful in the planning and coordinating of changes so as to prevent unwanted downtime.

Likewise, the Incident Management process (with the Service Desk) utilizes the relationship data in the CMDB to determine the impact of an unplanned outage event on the user community or on defined service levels. The Service Desk can also use the CMDB to discover whether the CI is associated with any known defects or errors. In this event, workarounds may also be available to resolve the situation and thereby minimize the impact on the IT service.

It’s also helpful for the Incident and Change Management processes to have a certain level of maturity before beginning Configuration Management. This is mostly because, there should be some idea as to what type of information will be best in helping these processes to be effective in achieving their objectives.

For example: what level of detail is required for the Incident Management process to be able to adequately resolve breakdowns in order to meet agreed service levels? For Change Management: What level of system detail is necessary to accurately assess the risk associated with a particular change so as to maintain the required level of stability.

In practice, these thresholds are usually different for different IT systems and services. Therefore, the decisions regarding the breadth and depth of your CMDB will depend largely on the level of control required for each IT system/service. This control will depend mostly on the importance and required system availability.

For each service, start with those CIs that:

• Are subject to change
• Are necessary to deliver a service
• Can be managed
• Can be uniquely identified

Once the scope of the CMDB has been decided, a detailed project plan should be created. This plan should probably be divided into several phases with discovery and CMDB population for each IT Service. This means that once the level of detail is defined for each IT Service within the project scope, this master plan should be divided into roll-out phases and outline all services included for each phase.

Each phase will include CI discovery tasks followed by CMDB population tasks. Additionally, auditing and verification (of data) tasks are also very important as the accuracy of the data is critical to the success of the database.

Each CI entered into the database should have an owner or someone who will be responsible for making sure that the data regarding that CI is both complete and accurate. The CI should also be assigned a unique identifier (CI Name) that will never change throughout the entire life cycle (i.e., CI purchase to retirement.) This means, that you should think twice before including any intelligence in the naming convention that references things which are subject to change (location, owner, host names etc.)

The name should make sense (i.e., servers begin with the letter s, perhaps) but should not be such that the name no longer makes sense when circumstances change (data center move, for example). This information can always be included in the CI attributes.

The naming convention should also be consistent across all environments. When deciding which relationships to map for each CI, consider first only the important relationships. This means, begin by describing in the CMDB, the most obvious relationships between CIs.

For servers, the important relationships might be what the server is connected to, which applications are running on the server, which services are dependent on the server, etc.

Once this has been decided, it is time to begin the population of the CMDB. Again, the CMDB can start off being something as simple as one or more excel spreadsheets.

What’s important is the process. A sound and well thought out process regarding the design of the CMDB as well as the ongoing maintenance of complete and accurate information are the keys to creating a successful and effective repository.

Good luck!