The Truth About Configuration Management and the CMDBCMDBs are not all-powerful, magical repositories of your sacred IT icons, writes ITSM Watch columnist Hank Marquis of itSM Solutions.
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 managementmaking better decisions regarding changes.
|Other Articles by Hank Marquis|
ISO-20000 and What it Means to You
Seven Steps to Improved Incident Handling
CFIA in 4 Easy Pieces
6 Steps to Service Outage Analysis
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.
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.