Tony Bishop

IT shops continually struggle with keeping resource documentation up to date. Too often IT departments seem resigned to accept mediocre results, as if the world conspires against them. Resource tracking is a prime example of this.

Fundamentally, the different organizational aspects refuse to comply with these manual processes to keep a CMDB updated. Furthermore, advancements in virtualization have made the situation worse, as software resources have been severed from physical resources. Traditional resource tracking methods are further confused as the virtual resources change physical location over time.

This reinforces the protests that an application's dependency profile is too complicated to be 100 percent accurate. Over time, IT has simply accepted the fact that it is totally impractical to keep the physical architecture records of systems up to date manually. Instead of trying to maintain the documentation, it is generated when needed through a time-consuming trial-and-error process, and by the time it is done, it is hopelessly out of date.

Not only is this an inefficient use of people's time, it's no way to manage some of the most important resources in an organization. These IT resources have become a digital backbone upon which most organizations are totally dependent for their very survival. The cavalier attitude toward managing IT resource inventory is dangerous at best and can prove to be catastrophic.

For instance, it's just a matter of time until the next large outage occurs. Despite the best-laid disaster recovery plans, technology has an uncanny ability to fail in unexpected ways; the combinatorial possibilities are immense. Having accurate application maps can make the difference between being the hero and goat. If individual self-preservation isn't motivating enough, there are other practical organizational reasons to keeping this information available: datacenter moves, chargeback models, and consumption analysis to name a few.

Generally this lack of inventory control has been accepted as the status quo despite the clear risks. In no other industry would such poor controls be acceptable. Imagine Wal-Mart's CEO explaining a lack of understanding of store inventory to Wall Street analysts. If such a story broke, he'd be out of a job before the ink dried. IT management shouldn't be allowed to get away with it either.

This is exceedingly frustrating, as application dependency mapping tools have become mature offerings. An application-dependency mapping tool uncovers the otherwise hidden relationships between applications and infrastructure resources. In our experience as former IT practitioners, we have implemented such capabilities. Our main goal was to get a better handle on inventory management and resource relationship for a datacenter move, but we quickly realized that there were many additional benefits we could take advantage of:

Identification of idle servers for reclamation (we were shocked at how many)

Identification of legacy infrastructure that poses a security threat (such as Windows 95/98)

Identification of production servers using development or test resources

Identification of changes to an environment over time, especially useful for figuring out "what changed" for debugging purposes

In addition, these tools provide a repository that supports a cradle-to-grave resource management policy. Firms should export this information into both a CMDB and a living blueprint platform for change management and system maturation purposes.