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.

Having an accurate and timely understanding of what is in production is vital to everyone in IT. So much so that many groups are rushing to implement automatic tools that promise to discover new and changed systems on the network.

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 isn’t the configuration data accurate today? Is it due to data entry error or because people aren’t 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.

Change Matters

Fundamentally, what groups don’t realize is their challenge isn’t 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 don’t 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 moment’s notice, then it is important enough to be governed by change management so the question “What changed?” can always be answered. The idea behind ITIL’s configuration management process is to have a logical view of the world that IT supports. This means understanding the hardware, software, documentation, people, services, facilities and how they relate to one another.

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.

Having an accurate and timely understanding of what is in production is vital to everyone in IT. So much so that many groups are rushing to implement automatic tools that promise to discover new and changed systems on the network.

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 isn’t the configuration data accurate today? Is it due to data entry error or because people aren’t 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.

Change Matters

Fundamentally, what groups don’t realize is their challenge isn’t 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 don’t 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 moment’s notice, then it is important enough to be governed by change management so the question “What changed?” can always be answered.
The idea behind ITIL’s configuration management process is to have a logical view of the world that IT supports. This means understanding the hardware, software, documentation, people, services, facilities and how they relate to one another.

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.

Having an accurate and timely understanding of what is in production is vital to everyone in IT. So much so that many groups are rushing to implement automatic tools that promise to discover new and changed systems on the network.

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 isn’t the configuration data accurate today? Is it due to data entry error or because people aren’t 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.

Change Matters

Fundamentally, what groups don’t realize is their challenge isn’t 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 don’t 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 moment’s notice, then it is important enough to be governed by change management so the question “What changed?” can always be answered.
Groups that fail to have proper change management fail to properly manage their organization’s risks. An automated configuration scanner that is implemented instead of change management, or instead of fixing what ails change management, is an incomplete band-aid fix that fails to address the true problem or, worse, simply masks the true nature of the problem.

Concerns over bureaucracy and slowing down the rate of changes need to be carefully scrutinized. Organizations that implement appropriately designed change management processes find their availability, integrity, overall security and agility actually improve as plans are scrutinized, errors detected and corrected, improvements factored in, right parties contacted, etc.

The objective is to design a controlled change management process that balances risk with agility and the ability to support attainment of organizational goals.

Tools Are Just Tools

The automated configuration detection tools are aids to processes, not replacements to processes. If change management is being bypassed then these should be flagged and investigated. The only level of unauthorized change that should be accepted by management is zero.

If something changed and there isn’t and approved RFC then corrective and appropriate disciplinary action should be taken. A recent IT Process Institute study on the value of controls identified the two controls present in high-performing IT organizations was the ability to detect unauthorized changes and the willingness to impose disciplinary action when processes were flagrantly disregarded.

In addition, these tools are trying to determine CI attribute details and CI relationships in a complex environment. Some of the assumptions/findings may not always be correct. Just because a change is detected doesn’t mean that the system is right.

If an organizations plans to import changes into the CMDB then someone must review the proposed updates first for accuracy to ensure that the CMDB’s data integrity is protected. Furthermore, to reinforce what was stated earlier, questions must be asked about why the changes transpired by mapping them back to approved RFCs.

In closing, these automated discovery tools can help organizations collect data but they must support processes designed to meet business needs. This means the goals of the business must be taken into account, then the IT requirements defined and then processes designed with the correct blend of people, process, and technology.

Simply buying the tools and running them is not the solution. Understanding why changes are happening and gaining control over the infrastructure via an effective change management process to better ensure availability, integrity and overall security must be the primary focus.