CMDB Systems are analogous to the so-called NOC War Room single pane of glass. And given that premise, here are a few 'voices from the trenches' taken from consulting and research.
In my last column, I described the growing evidence that CMDB Systems (as in ITIL v3’s Configuration Management System) are beginning to support network operations teams as well as more traditional service desk and data center adopters. I made the analogy between the CMDB Systems of the present and future, and the NOC War Room single pane of glass – as IT organizations evolve to combine change management control with performance management and service assurance. This would enable IT to manage processes for reconfiguring critical network and systems devices while providing good dynamic visibility into actual configuration changes, service performance and service impact.
Once you see CMDB Systems in that light, it’s easier to make the bridge to the so-called War Room.
And given that premise, here are a few “voices from the trenches” taken from consulting and research over the last two years, including right up into the present.
One of the most compelling testimonies is in fact two years old, as an infrastructure-wide deployment, including network management, consolidated monitoring tools and health desk capabilities in a large financial services organization that charged for its IT support to multiple financial services companies:
“Our CMDB was an attempt to achieve world-class availability and at the same time control costs. With a $1 million in downtime for our whole ecosystem, and supporting 6,000 transactions a second, we reduced MTTR [mean time to recovery] by 70% through the CMDB initiative.”
In this case, data was accessed based on carefully defined “trusted sources” so that conflicting views of the same device or device attribute weren’t guaranteed to lead to a finger-pointing exercise. Consistent sources enabled better dialog and collaboration in resolving cross-domain issues. And the biggest challenge was, as usual, not technological but political.
Another voice from the trenches comes from an management service provider with responsibility for managing network and other devices across multiple organizations:
“Over the past three years, we’ve tied the CMDB in the change process, and then made sure that it would be supportive of our financial processes and financial systems. Over the course of the last three years we successfully disputed $2.5 million out of a $9 million spend.”
Here the clarity of knowing what you own, what services you’re getting, and what you’re responsible for managing saved this organization significant dollars.
A large communications and media services organization relayed a fairly telling story last year:
“We’ve been dreaming of a CMDB for seven years, well before anybody said the word ‘CMDB.’ We were in the process of developing our own internal software for the system when the idea of a CMDB System really took off. We started by developing a map of inventory and assets as they impacted services." This person managed a three-person team focused on the deployment. They included ITIL training, “not so much to become ITIL-compliant as to move the broader initiative forward."
The single biggest driver was that this organization hosts a number of Web sites, and when a Web site had problem, it was “impossible to understand the broader ramifications in terms of customer and service impact, as well as to understand who had what type of management responsibility across the infrastructure.” By providing a cohesive picture of the infrastructure and the services it supported, the CMDB initiative would help to enable better maintenance, capacity planning, change management, incident management, configuration management, problem management, service quality, along with other disciplines.
Another objective was to lower the skill level for tech support personnel – and this meant visualizing interdependencies across the infrastructure. This individual complained that “network devices are under-represented” in the enterprise-class CMDB solution they chose, but nonetheless has begun to see real benefits from his CMDB System deployments.
Another network ops-driven CMDB initiative, this time in a large bank, is targeted at keeping a good physical inventory along with a federated set of sources for consistent monitoring. The CMDB System is “being driven from the network upwards because the network sits at the base of everything.” Among the goals are better application performance across distributed environments, support for a VoIP initiative, better asset and change management, and more effective management of WAN services from service providers.
Another company, also in financial services, reported spending $8 million in consulting and operational costs on a survey to inventory critical devices and their owners – a survey that immediately became time-obsolete as soon as it was completed. A $3 million CMDB System investment is leading towards a dynamically current approach to capture the same information, while laying the foundation to achieve a whole host of other benefits.
And finally, an overseas telecommunications service provider launched its CMDB initiative because it was carrying 30% extra operational overhead, it needed to consolidate its Service Delivery organization from 250 to 160, and 70% of the outgoing calls were being circulated across their telecommunications organization in, to use my own words, Brownian motion. “The CMDB is helping to provide a much more consistent and effective way of sharing information.”
And of course these are just a few examples. In closing, I have to say that I read with some interest a complaint from my prior article by a self-proclaimed Archie Bunker whose main point seemed to be (as best I could tell) that CMDBs add unneeded complexity. And of course that is a valid concern. Some poorly managed CMDB projects, in the NOC or otherwise, do just and only that.
But “complexity” is a good point to bring up, because the thing about CMDB Systems is that they should do just the opposite. They should eliminate the “complexity” of feuding toolsets arming feuding professionals with fragmented processes for managing change and resolving problems. What could be more complex, for instance, than the many redundant and poorly maintained sources for asset information (including Visio drawings and Excel spreadsheets) in most companies? Simplicity, flexibility and consistency should be, in my view, the three key attributes of well-planned CMDB Systems, something that, NOC or no NOC, it’s all too easy to forget.