CMDB: Truly reaping the rewards

The continued demand for IT efficiency, business accountability and compliance has led many IT organisations to explore clarifying and re-engineering their infrastructure processes.

In SA, this has inspired an increased interest in the ITIL (IT Infrastructure Library) methodology`s best practices. Consequently, enterprise management software vendors have increased their focus on ITIL enablement, especially the CMDB (configuration management database).

Today, CMDB is at the core of many ITIL business function practices such as availability management, capacity planning, change management and risk management. While ITIL does not specify a CMDB implementation, its best practices do influence the choice among implementations.

The following four questions are the foundation for choosing or designing a CMDB implementation, or any other data management system: (1) What is the source of the data? (2) How can the accuracy of the data be verified? (3) How is the data used? (4) How is the data retrieved?

Ultimately, the purpose of the IT organisation is to provide IT services efficiently and reliably. To do this, they have to implement specific infrastructure management utilities.

Each of these utilities adds to the store of information IT has about itself.

These information sources include:
* Network and system monitoring services detect the operational state of devices, network connections and applications.
* Asset discovery tools use various means to detect which devices are on the network and what is installed upon them.
* Asset financial management tools track the financial documents and agreements that are associated with configuration items before, during, and after an asset is deployed on the network.
* Change management application to plan and record changes to the configuration, including the deployment, modification, reconfiguration and decommissioning of devices and systems.
* Service delivery tools, such as service catalogues, track the services delivered by the IT department.
* Service desks track the incidents and problems associated with configuration items and document contacts with the physical users of configuration items and the IT support organisation.
* Manual information sources that include visual inventories and written configuration records.

However, it is often more complicated as organisations have several independent implementations of one of the sources described above. The site has installed applications from various software vendors. They have developed their own applications in-house.

Although configuration management is not a panacea, it can help solve many problems. The first step in reaping additional gains is to look at the potential. For example, companies that use configuration management with a CMDB strategy are able to track, control and report on IT assets, which in turn, aids compliance with regulations such as Sarbanes-Oxley.

Also, it can enhance overall performance and decrease hardware expenses with system designs based on configuration facts, ultimately improving system performance.

However, it should be noted that a service desk-based CMDB will not offer these benefits. In this light, IT infrastructure management vendors have begun mobilising to find it workable solution.

A Federated CMDB has it origins in the service desk CMDB arena. A service desk is a single application with a single table or group of tables that represent configuration items. Whether service desk is the starting point or not, data from a single application never provides the full picture for configuration management.

In fact, a CMDB implementation based on a single application like service desk will not yield these benefits. The first requirement is that the CMDB must support the jumble of information sources that is at the heart of the problem. The approaches to this problem have taken two directions: federation and centralisation.

A federated CMDB is a single virtual database that is built from several independent databases. Data is physically moved into the central database from the peripheral federation or incorporated by using the capability of the underlying database management system to include data from remote databases.

A federated CMDB can be contrasted with a centralised CMDB where the preponderance of data is incorporated in a single central schema.

There are difficulties involved in the federated approach:
1. System overhead is typically high. Batch loads and replication can consume considerable resources, particularly if the data is refreshed frequently.
2. Maintenance and reliability may be an issue. Connecting middleware between the CMDB and external systems tends to be fragile and expensive.
3. The recurring investment maintaining relationships between federated systems can be enormous. System connections are very sensitive to release upgrades and other configuration changes.

The key here is that costly maintenance due to a federated approach to data management, will be to the account of the customer, after the implementation has been completed.

An MDB (management database) solves a number of the federated CMDB problems.

As a database implementation, an MDB is intended to serve as more than the data repository for a CMDB practice - it is built on the requirements of a large number of applications, not just the applications that relate to the practice.

Prior to MDB, IT organisations that wanted to derive benefits from a CMDB practice had no choice but to use a federated data model, which spreads data between independent databases. MDB solves federation problems with a centralised approach, providing innovative enterprise solutions that enable industry standards like ITIL.