Accurate Configurations -Technology Alone Isn't the AnswerChange management is really the heart of configuration management, writes ITSM Watch columnist George Spafford.
The desire is for an IT person with appropriate authority to be able to access the data and understand, for example, what hardware and software make up a given server? What component configuration items (CIs) make up a service and how they relate to one another.
Like any tool, these automated systems have a time and a place but groups must understand the causality of their configuration management concerns before simply buying one of these tools and putting it into production.
In principle, these automated tools scan the network and/or monitor network traffic on a defined interval and can then load their findings directly into the configuration management database (CMDB). The premise behind these tools is configuration management takes a lot of work so why not implement systems to do the mundane data collection faster and more accurately.
The siren song is that by implementing these tools the vital configuration management data will finally be accurate and current for everyone to benefit from.
The issue to consider is why isnt the configuration data accurate today? Is it due to data entry error or because people arent recording the changes to the infrastructure to begin with? In some cases there are errors with the recording but the bigger problem relates most likely to uncontrolled changes in the form of new systems and changes to existing systems not being recorded into the CMDB.
Fundamentally, what groups dont realize is their challenge isnt with configuration management. It is with change management. Change management is the process by which an organization implements the necessary procedures to control changes to production and thus manage risk.
It is very important to understand that change management governs configuration management nothing should change in production, or the CMDB, without an approved Request for Change (RFC). If production is changing and nobody knows about it, then this is a change management failure not a configuration management failure.
Systems dont magically change overnight on their own. Somebody changed them for some reason. If a service is important for an organization to know the configuration at a moments notice, then it is important enough to be governed by change management so the question What changed? can always be answered.