Configuration Management Technology

Configuration Management Technology has come a long way in the last few years!  We’ve now come a long way from the times where there were very few applications available to manage Configuration Management. Yet some organizations still keep a spreadsheet or a simple database to reflect the Configuration Management of their Organizations!

What should we expect from the Configuration management Technology that is currently available?

Configuration Management Technology - What it should provide

The Configuration Management system should prevent Changes from being made to an IT infrastructure without valid authorization via Change Management. The authorization record should automatically 'drive' the Change.

As far as possible, all Changes should be recorded in the CMDB at least by the time that the Change is implemented. The status (e.g. 'live', 'archive', etc) of each CI affected by a Change should be updated automatically if possible.

Example ways in which this automatic recording of Changes could be implemented include automatic updating of the CMDB when software is moved between libraries (e.g. from 'acceptance test' to 'live', or from 'live' to an 'archive' library), when the service catalogue is changed, and when a Release is distributed.

Configuration Management Technology - What should I be looking for?

Now this is all well and good, but if I were to differentiate between products what else should I be looking for? A good starting point would be to think of the things that would make your job a lot easier, such as:

• Sufficient security controls to limit access on a need-to-know basis.
• Support for CIs of varying complexity e.g. entire systems, Releases, single hardware items, software modules, or hierarchic and networked relationships between CIs; by holding information on the relationships between CIs, Configuration Management tools facilitate the impact assessment of RFC’s.
• Easy addition of new CIs and deletion of old CIs.
• Automatic validation of input data (e.g. are all CI names unique).
• Automatic establishment of all relationships that can be automatically established, when new CIs are added.
• Support for CIs with different model numbers, version numbers, and copy numbers.
• Automatic identification of other affected CIs when any CI is the subject of an Incident report/record, Problem record, Known Error Record or RFC.
• Integration of Problem Management data within the CMDB, or at least an interface from the Configuration Management system to any separate Problem Management databases that may exist.
• Automatic updating and recording of the version number of a CI if the version number of any component CI is changed.
• maintenance of a history of all CIs (both a historical record of the current version - such as installation date, records of Changes, previous locations, etc - and of previous versions).
• Support for the management and use of configuration baselines (corresponding to definitive copies, versions etc), including support for reversion to trusted versions.
• Ease of interrogation of the CMDB and good reporting facilities, including trend analysis (e.g. the ability to identify the number of RFC’s affecting particular CIs).
• Ease of reporting of the CI inventory so as to facilitate configuration audits.
• Flexible reporting tools to facilitate impact analyses.
• The ability to show graphically the configuration or network maps of interconnected CIs, and to input information about new CIs via such maps.
• The ability to show the hierarchy of relationships between 'parent' CIs and 'child' CIs.

This list should give you a good starting point to think of those things that you have as processes currently and which of those can benefit from automation.