The Truth About Configuration Management and the CMDB
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.
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 informationyou 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 anywayyour ticketing systemas 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!