However, the use of ITIL over-generalizations like “account for all the IT assets and configurations within the organization and its services” can cause new practitioners to become confused and overwhelmed. Coupled with vendor hype and management misunderstanding, practitioners quickly lose sight of the single reason for configuration management—making better decisions regarding changes.

Purchasing or building a configuration management product is expensive. But there is an alternate approach: using the configuration management systems virtually ever organization already has in place. These existing, and often overlooked, existing systems deliver real value for little or no additional cost.

True Colors

Regardless of what you've heard, read, or seen, the real purpose of configuration management is to empower better decision making in order to control changes through creation and maintenance of documentation. This is not the same as change management, which is a process for evaluating and handling change requests in the pursuit of quality of service improvement.

Configuration management is a process to identify, record, maintain, report on, and verify documentation. Change management and other ITIL processes use this documentation to make better decisions. The activities of configuration management all relate to the simple idea of creating and maintaining a database of information regarding CIs (configuration items), and then inserting the usage of this database into the decision-making process.

This simple understanding is the path to success regarding configuration management, and the establishment of the CMDB.

The Truth About CMDB

Many think the CMDB is a single, all-powerful database with amazing abilities never intended and often not required. Many vendors inadvertently contribute to this confusion with claims of functionality based on their unique capabilities.

If I could rename the CMDB, I would call it the configuration management databank. This sounds simple, but a large part of the problem practitioners have with configuration management stems from the use of the word database and what people think the word database means.

Webster defines database as “a usually large collection of data organized especially for rapid search and retrieval.” Many have forgotten (or never knew) that databases consist of one or more banks or repositories of data.

Webster defines “databank” as an alternate term for “database.” While it is true that a database or databank can be a single entity, databanks are often independent, and often geographically distributed among several repositories.

Many think a database is a single thing and most think it has to be software, but catalogs and index card systems are also databases. Because most think software (SQL, Oracle, etc.) when they think database the result is confusion and trepidation.

These conditions lead to the mistaken belief by practitioners that configuration management and the CMDB are more than they really are. In truth, there is no such thing as a "single file" CMDB. If I were to call the CMDB anything, I would call it a type of hypertext engine, and if could describe the role of configuration management I would call it “information brokering.”

In a hypertext system, any object, whether it describes a piece of data (e.g., text, video, audio) or a physical thing (e.g., hardware, software, person, building, or document) can link to any other object. It does not matter where, physically, the object resides. Hypertext systems are particularly useful for organizing large amounts of disparate information. The World Wide Web (WWW) is a hypertext system that is clearly not a single database.

However, the use of ITIL over-generalizations like “account for all the IT assets and configurations within the organization and its services” can cause new practitioners to become confused and overwhelmed. Coupled with vendor hype and management misunderstanding, practitioners quickly lose sight of the single reason for configuration management—making better decisions regarding changes.

Purchasing or building a configuration management product is expensive. But there is an alternate approach: using the configuration management systems virtually ever organization already has in place. These existing, and often overlooked, existing systems deliver real value for little or no additional cost.

True Colors

Regardless of what you've heard, read, or seen, the real purpose of configuration management is to empower better decision making in order to control changes through creation and maintenance of documentation. This is not the same as change management, which is a process for evaluating and handling change requests in the pursuit of quality of service improvement.

Configuration management is a process to identify, record, maintain, report on, and verify documentation. Change management and other ITIL processes use this documentation to make better decisions. The activities of configuration management all relate to the simple idea of creating and maintaining a database of information regarding CIs (configuration items), and then inserting the usage of this database into the decision-making process.

This simple understanding is the path to success regarding configuration management, and the establishment of the CMDB.

The Truth About CMDB

Many think the CMDB is a single, all-powerful database with amazing abilities never intended and often not required. Many vendors inadvertently contribute to this confusion with claims of functionality based on their unique capabilities.

If I could rename the CMDB, I would call it the configuration management databank. This sounds simple, but a large part of the problem practitioners have with configuration management stems from the use of the word database and what people think the word database means.

Webster defines database as “a usually large collection of data organized especially for rapid search and retrieval.” Many have forgotten (or never knew) that databases consist of one or more banks or repositories of data.

Webster defines “databank” as an alternate term for “database.” While it is true that a database or databank can be a single entity, databanks are often independent, and often geographically distributed among several repositories.

Many think a database is a single thing and most think it has to be software, but catalogs and index card systems are also databases. Because most think software (SQL, Oracle, etc.) when they think database the result is confusion and trepidation.

These conditions lead to the mistaken belief by practitioners that configuration management and the CMDB are more than they really are. In truth, there is no such thing as a "single file" CMDB. If I were to call the CMDB anything, I would call it a type of hypertext engine, and if could describe the role of configuration management I would call it “information brokering.”

In a hypertext system, any object, whether it describes a piece of data (e.g., text, video, audio) or a physical thing (e.g., hardware, software, person, building, or document) can link to any other object. It does not matter where, physically, the object resides. Hypertext systems are particularly useful for organizing large amounts of disparate information. The World Wide Web (WWW) is a hypertext system that is clearly not a single database.

However, the use of ITIL over-generalizations like “account for all the IT assets and configurations within the organization and its services” can cause new practitioners to become confused and overwhelmed. Coupled with vendor hype and management misunderstanding, practitioners quickly lose sight of the single reason for configuration management—making better decisions regarding changes.

Purchasing or building a configuration management product is expensive. But there is an alternate approach: using the configuration management systems virtually ever organization already has in place. These existing, and often overlooked, existing systems deliver real value for little or no additional cost.

True Colors

Regardless of what you've heard, read, or seen, the real purpose of configuration management is to empower better decision making in order to control changes through creation and maintenance of documentation. This is not the same as change management, which is a process for evaluating and handling change requests in the pursuit of quality of service improvement.

Configuration management is a process to identify, record, maintain, report on, and verify documentation. Change management and other ITIL processes use this documentation to make better decisions. The activities of configuration management all relate to the simple idea of creating and maintaining a database of information regarding CIs (configuration items), and then inserting the usage of this database into the decision-making process.

This simple understanding is the path to success regarding configuration management, and the establishment of the CMDB.

The Truth About CMDB

Many think the CMDB is a single, all-powerful database with amazing abilities never intended and often not required. Many vendors inadvertently contribute to this confusion with claims of functionality based on their unique capabilities.

If I could rename the CMDB, I would call it the configuration management databank. This sounds simple, but a large part of the problem practitioners have with configuration management stems from the use of the word database and what people think the word database means.

Webster defines database as “a usually large collection of data organized especially for rapid search and retrieval.” Many have forgotten (or never knew) that databases consist of one or more banks or repositories of data.

Webster defines “databank” as an alternate term for “database.” While it is true that a database or databank can be a single entity, databanks are often independent, and often geographically distributed among several repositories.

Many think a database is a single thing and most think it has to be software, but catalogs and index card systems are also databases. Because most think software (SQL, Oracle, etc.) when they think database the result is confusion and trepidation.

These conditions lead to the mistaken belief by practitioners that configuration management and the CMDB are more than they really are. In truth, there is no such thing as a "single file" CMDB. If I were to call the CMDB anything, I would call it a type of hypertext engine, and if could describe the role of configuration management I would call it “information brokering.”

In a hypertext system, any object, whether it describes a piece of data (e.g., text, video, audio) or a physical thing (e.g., hardware, software, person, building, or document) can link to any other object. It does not matter where, physically, the object resides. Hypertext systems are particularly useful for organizing large amounts of disparate information. The World Wide Web (WWW) is a hypertext system that is clearly not a single database.

The CMDB, like the WWW, is a logical construct that references many sources of information and physical objects. This is technically called a metabase (sometimes called a metadatabase or metadata repository). A metabase is a database for storing data that describes data. Stay with me here! For example, a metabase might include metadata about all configuration information regarding a system gathered from a number of sources.

So forget the idea of the single, all-encompassing, database. Start thinking about linking together all the collections of information you use in your day-to-day activities. Start thinking about how to reference and relate the repositories of CI information you already have.

Uncovering Your Own CMDB

Once you understand what the CMDB really is, you can start to think about uncovering your own repositories of information. IT organizations often have much of the data but lack a process for managing and using the data. Without such management control, the data is not kept up-to-date and is not available to other processes.

I say uncovering because virtually every single IT organization already has repositories of information—you probably just never thought of it this way before.

Somewhere in your organization there are records regarding hardware and software. You have manuals and software nearby. Someone has an Excel spreadsheet to document office system configurations. Finance has an asset register tracking purchases.

Elsewhere someone is using Microsoft Access to track software licenses. Then there are user manuals, closets with spare hardware, and diagrams of services, circuits, and systems in Visio or maybe PowerPoint.

The first step is to locate all of the sources of information relating to your infrastructure. Don't worry about a single repository for Incident, Problem, Known Error, and Change records, hardware, software, and services for now. You probably already have a system that tracks Incidents, Problems, and Known Errors or their equivalent right now anyway—your ticketing system—as one of the repositories within your CMDB.

Focus instead on the CIs relevant to delivering your vital services. Locate the existing information repositories, but leave them in their current form for now. Your goal is not to impose major new projects on existing teams, but rather to locate sources of data and formalize their maintenance and control. Your goal is to broker access to this data to those who need it.

Once you know where your CI information resides, the next step is to arrange the sources of CI data into a structure, a metabase. This does not always require investments in new systems or software development. Depending on your size, maturity, and unique requirements, your CMDB solution will vary.

You could create a spreadsheet of where your configuration information resides. You could create relational systems tying together existing tools and systems such as Human Resource directories, ticketing systems, asset registers, log files, and any other appropriate source of data.

I have used extremely effective systems based on wildly different methods from paper "circuit layout records" to large-scale software solutions that automatically integrated asset discovery and service monitoring. Each was extremely effective and efficient for the tasks required.

However you proceed, beware falling down the slippery slope of thinking configuration management and the CMDB are things you have to purchase or develop. Start small, and grow as you mature. Follow the simple steps of locating the sources of data, taking them under management control, and creating a system for knowing what is where.

This simple plan gives you a real CMDB that you can use to realize the benefits of CM!

Hank Marquis is a managing partner and CTO at itSM Solutions. You can contact Hank at hank.marquis@itsmsolutions.com.