Lots of thoughtful observations with an underlying issue that change, capacity, service and other management disciplines rely on knowing the underlying dependencies between hardware, virtual systems, software and services. This was a conclusion by the ITIL authors who said a cmdb was the best way to go - as a concept. In practice its’ not so easy, but a bit of work in this area does deliver the step change in controls, as long as you don’t try to build a cmdb yourself.

My day job is applying configuration management to large infrastructures with many 1000s of servers in different customers, mainly in the finance sector. We define the differences between hardware, blades, virtual servers, partitions, LPARs etc. as well as applications and services so that we can produce service views - basically a heirarchy with a service at the top and 1000s of platforms at the bottom. This is put into a database (service desk cmdb or whatever) from we derive service relationships. These are the maintained service views used by multiple teams.

Then we impose change, incident, problem, capacity, recovery status, end of life, ownership and other numbers or colour codes to communicate risks, hot spots, interrelated events and so on. As a technique it works, maybe its’ even an ITIL CMDB in practice - though I’ve never seen one that meets all the suggested attributes.

Few do this in practice as they don’t have the maturity of organisation to focus on process needs across teams. But things are changing as it is common sense not reverse engineer IT infrastructure with every project, change, incident or recovery plan. Reverse engineering a virtualised infrastructure and explaining is less time consuming than physically auditing boxes, but still complex enough to make it worth doing once.

Dave

Managing service levels was as important then as it is today…lest we become “overdrawn at the memory bank” (or CPU, or SAN, or ${your_favorite_resource_here})

– Margaret Leber CCP, SCJP, SCWCD http://voicenet.com/~maggie/mslresume.pdf