Configuration Management
Classification and Recording
The main task of Configuration Management is maintaining the CMDB. In order to carry out this task successfully, it is essential to define the structure of the CMDB such that:
- The objectives are realistic: excessive depth or detail could overload the organisation and, in the long term, lead to responsibilities being abandoned.
- The information is sufficient: there must be, at least, a record of all the critical systems for the IT infrastructure.
Scope
First of all we need to decide what IT systems and components are going to be included in the CMDB:
- It is essential that at least the hardware and software systems involved in critical services are included.
- It is necessary to determine which CIs should be included, as a function of their status within their lifecycle. For example, there is no need to include components which have been withdrawn from service.
- It is advisable at least to include the documentation associated with projects, SLAs and licences.
In general, any service or process may be included in the CMDB, but excessively ambitious objectives may turn out to be counterproductive.
Depth and level of detail
Once the scope of the CMDB has been determined, it is essential to establish the desired depth and level of detail:
- To determine the attributes that describe a given CI.
- Type of logical and physical relationships between the various CIs.
- Sub-components recorded independently.
For example, if you decide to include desktop PCs in the CMDB:
- Attributes: Date of purchase, manufacturer, processor, operating system, owner, condition, cost, etc.
- Relationships: network connection, printers connected, etc.
- Depth: NICs, hard drives, graphics cards, etc.
Naming conventions
Although this is a highly technical aspect, it is of vital importance to predefine the codes with which to classify the CIs in order for the system to work:
- The identification must, of course, be unique, and if possible it should be possible for users to interpret it.
- The code should be used in all communications referring to each CI and if possible, it should be physically attached to it (using a label that will not come off easily).
- The codes should not be used only for hardware components, but for documentation and software as well.
