Newsletters

Of all of the Infrastructure Technology Infrastructure Library (ITIL) processes, the Configuration Management Database (CMDB) has achieved an almost mystic and seemingly impenetrable aura.

Just about everyone has their own interpretation of a CMDB. Talk to five ITIL experts and you may well obtain five different interpretations.

Most ITIL gurus believe it is one of the core elements of ITIL success. Without a CMDB, an organization is limited in how well it can perform other ITIL processes such as change management, incident management, and problem management.

What is a CMDB?
In simple terms, a CMDB is a collection of status information about various technology components (known as configuration items, or CIs) such as servers, network devices, and databases and how they relate to each other. The relationships include the ability to see which components come together to deliver applications and services that are meaningful to a customer, such as an order processing system.

The value of a CMDB is in being able to visualize how the individual components fit together to support business applications rather than simply seeing a list of independent devices. This allows you to better assess the potential business impact of making a change to one or more technology components prior to implementing the change. Additionally, it can assist in speeding up the process of isolating the root cause of a problem when a business application is not behaving normally.

How is this relevant in the real world? Take the case of an IT organization that is struggling to deliver the required level of end-to-end availability of a high profile service such as a customer-facing website for online banking. Typically there are many different hardware and software components that must function in harmony for the website to be available and smoothly process customer transactions. One of the largest causes of unplanned system downtime is the unintentional side effects of implementing changes. A server being updated with a security patch might result in the online banking system slowing down or stopping altogether from the customer’s perspective. A CMDB can help reduce the risk that this problem would occur in the first place, and can isolate the cause of the problem if it does occur so it is quickly resolved by technical support people.

Setting up a CMDB
While a CMDB is an incredibly valuable tool, it must be understood at the outset that its implementation is a large and often daunting effort, especially for medium to large IT shops. After all, the CMDB is the single book of record for information relating to significant IT infrastructure components in the enterprise – desktop PCs, laptops, printers, servers, data storage devices, routers, network devices, telecom lines, etc.

The CMDB, then, is a core part of ITIL’s configuration management process. In general terms, configuration management deals with the identification, recording, and reporting of IT components, and their relationships. CMDB, then, gathers together all CIs. This includes physical devices such as those listed in the previous paragraph, as well as CDs, documents, etc.

Each CI has to be recorded in terms of its current status, its history (changes, who originated it, etc.), attributes (name, serial number, version, amount of memory, etc.), and interrelationships with other CIs.

Here is a snapshot of the type of data that might be included in a CMDB:

• Hardware information including model, Bios, memory installed, amount of internal data storage, peripherals attached (mouse, PDA, keyboard, etc)
• Operating system information including version, patch levels
• 3rd party support application (such as non-OS vendor anti-virus, storage management, etc.) information and release/version levels and patch levels
• Application software information include version, patch levels
• Network information such as telecom line speeds, patch panels and attached support, diagnostic equipment
• Past, current, and planned changes to hardware, software and network components
• Equipment and software costs including depreciation, lease information
• Software license information for license management purposes
• Maintenance information, including vendors, hours of support, contact information, escalation procedures
• Service level agreement information
• Internal problem management contacts, pager/cell phone contact info
• Setup instructions and configuration details
• Run documents, instructions (step-by-step information for computer operators such as start-up, shut-down, error recovery)
• Users that attach to the system
• Application dependencies

Because the CMDB is often so detailed and all-encompassing, it should be an automated system. Large shops could have many thousands of devices and telecom lines listed so manual management processes would be quite unmanageable and subject to error.

Making life easier for the system administrator
The system administrator (SA) is helped by the CMDB in many ways. The system administrator’s life is made easier by having all setup information and history quickly available to support day-to-day management tasks and problem determination efforts. Having this information, of course, permits the SA to recover from errors and reconstitute the server if it is damaged or destroyed.

But there are other ways in which the SA is assisted by the CMDB. Since all license information is in the database, the SA can ensure the enterprise complies with all license terms and conditions. In addition, the SA can quickly determine which servers need a particular patch, perhaps to correct a problem or close a potential security hole. It is no small thing to have all the information the SA uses in day-to-day work in a single repository and up-to-date. This eliminates a whole lot of searching and avoids mistakes being made because the documentation is out of date.

Making life easier for the capacity planner
The job of the capacity planner can be simplified by a CMDB. For example, financial information within the CMDB can assist the capacity planner in server replacement and consolidation decisions. If a decommissioned server has depreciation remaining at the time of decommissioning, the underappreciated amount is immediately incurred as an expense rather than amortized over the remaining months. As a result, cash flow and current year budgets are adversely impacted. It is important to know such facts before acting.

As another example, a CMDB will typically house useful data such as relationships between services and the infrastructure components used to implement those services. With a little effort, this kind of information can be used during the workload definition process, allowing TeamQuest Performance Software to determine the portion of various system components used on behalf of each business service or IT service.

The relationships between services and infrastructure components can also be imported by TeamQuest Performance Software from a CMDB in XML format. This process will create the TeamQuest IT Resource definitions needed to simplify analysis and reporting on performance in terms of business service or IT services rather than as a long list of individual infrastructure components.

Conversely, if you already have your IT Resources defined in a TeamQuest Capacity Management Database (CDB), you can export those in XML to make it easy to copy them into your CMDB.

Bottom line for the capacity planner: more accurate service/component dependency information, forecasts, system configuration details, and financial details, permit the building of better capacity plans and predictive capacity models.

Simplifying the CMDB
Recognize, however, that implementing a CMDB strategy and associated tools will require a serious commitment of time and resources. The best advice is not to attempt to put the entire systems infrastructure in the CMDB. Start with a narrow scope, such as the software and devices that support a single critical IT service or application that is experiencing problems. That will simplify the problem you are trying to address and increase your ability to realize benefits from a CMDB.

Even then, a CMDB is never an easy task, and it is difficult to quantify its benefits in financial terms. In most cases, therefore, Capacity Management is probably a better place to start. It provides rapid returns without much risk. And the payoff may be sufficient to pay for the rest of the ITIL implementation.