In my last blog I laid out the proposition that Configuration Management and a CMDB is all about Change and that CMDB and Change are ‘partners’ in executing the work of IT efficiently and accurately. Seems pretty clear, right? Then it should be easy to justify and implement a CMDB based on large numbers of Changes, right again?

Not necessarily. Justifying, developing and implementing a CMDB is not an isolated activity, a technology implementation or a database development effort. A CMDB is a means to an end, not an end in itself, and the end(s) are increased ITIL best practice Change Management and control and increased Configuration and Release Management control.

Continue Reading…

Is the business value of a CMDB all about Change Control? And what if your organization performs root cause analysis? Do you really need a CMDB? We’ll address these and other CMDB, Change and Configuration Management issues in a new series of blogs this month.

As enterprises and their IT support organizations grow, their infrastructures become increasingly fragmented and spread across a variety of functions, technologies and organizations. As this IT infrastructure ‘sprawl’ continues, efficiency, optimization and overall control over IT resources suffers. Organizations often address the IT infrastructure ‘sprawl’ issue with automated or, in some cases manual, Change ‘root cause’ analysis tools. These tools analyze changes, in many cases failed changes, to get at the ‘root cause’ of the problem.

Continue Reading…