A configuration management database, or CMDB, is a listing of computer and software assets with locations, descriptions and details of their configuration. Its purpose is to help IT management determine what changes are necessary in the configurations of the company's IT systems, based on the configurations in place. To fulfill this purpose, the CMDB must be detailed and exhaustive to give basic information on configuration of IT assets but it must also contain information on the location of assets, such as original software disks, to allow implementation of changes once the corresponding decisions have been made.
Decide on the scope of the CMDB. Computers, standard corporate software and computer peripherals should definitely be included. Decide whether to include mobile devices. Decide whether to include custom software used by only one department. Identify any other IT assets and decide whether to include them. Document the reasons for the decisions.
Decide on the purpose of the CMDB. Consider the purpose together with the scope. Make decisions on the scope that support and enhance the purpose of the database. One purpose could be to support the IT department in making changes. Another could be to help with technical support for company staff. Still another could be to develop an effective policy and procedural framework for data backup. Get buy-in from stakeholders who will be affected by showing them benefits derived from the creation of the CMDB.
Set up the database structure. A first field should be for an asset ID or code that describes the type of asset and gives a unique identifier. A second field should give a brief description. A third field should give the physical location. A fourth field should give the acquisition date. A fifth field should give the physical location of the file containing relevant documentation such as warranty, purchase details, price, manuals and configuration details. A sixth field should identify the employee who is responsible for the asset and for its documentation. Add additional fields as required and, if there is a wide divergence of fields required for different asset classes, it may make sense to split the database into several databases, each dealing with a particular asset class.
Fill in the data. Initially data should be taken from existing records but, eventually, the data must be verified by actual audits and inventory verification. At this time it will become clear how accurate existing records are and whether modifications to existing procedures for developing and keeping records of IT assets will be necessary. The creation of the database is only the first step. To be useful and fulfill its purpose, it must be continuously updated and its accuracy over time ensured.