The rise of CMDB System adoptions is striking. Data from EMA research shows that out of 75 respondents in healthcare and financial services with $1 billion in revenue or more, every one of them plans to implement a CMDB System.
The rise of Configuration Management Database (CMDB) System adoptions is striking. Data from EMA research just completed in February shows that out of 75 respondents in healthcare and financial services with $1 billion in revenue or more, every one of them plans to implement a CMDB System (while 28% had “no plans” in 2006).
Thirty-seven percent had already implemented, at some level, a CMDB System, compared to a mere 8% in 2006, and 30% are “in the process of implementing,” compared with about 14% in 2006. (Other options for planning to implement fill out the rest of the percentages, for those of you who like to count to 100.)
On the other hand, as is probably evident to many of you, network operations are not normally the driver here. Most CMDB System deployments seem to come out of the data center or most generally “operations overall,” most often with an eye to the network, but with the network group behaving, well, like the Archie Bunkers in the mix. (Archie Bunkers = hold outs for a past era when things were presumably “simpler.”)
Out of about 30 focal interviews, including some EMA consulting engagements, I have identified exactly six examples with very strong network content and only four where network operations were actually driving the initiative. Again, that isn’t to say that there weren’t a good number of deployments where network operations were included at some level, but there were only six where, say, the network was paramount.
There are no doubt multiple reasons for this, and I’m planning some serious research in May to tackle this and other issues relating to the changing role of network operations. This should bring some new insights to the question posed above – with much more quantitative data. But between past research, current dialogs, and those times when I’m pulled into dialogs to support our consulting (versus analyst) efforts, I’m comfortable putting at least a stake in the ground now.
One of the obvious issues is that very few people - including many other analysts, I’m told - understand what a CMDB System is. “CMDB System” is EMA’s term that parallels ITILv3’s term “Configuration Management System” or CMS.
This comes from EMA’s notion that the future of management in general is “federated data stores to support cooperative analytic engines.” It is a multi-brand vision and it is very much both “real-time” and “process-control-desired-state.” In other words, it is analogous to combining the NOC war room with a configuration and change control system designed to support consistent reviews and approvals rather than cowboy-like actions on long weekends. This reflexive system, designed to automate insights into desired states with discovered states and support for process and best practice requirements, is what CMDBs should be all about -- at least long-term.
And in terms of vision, at least, this has been true in virtually all the accounts where I’ve been involved. But to do this you don’t need a single, hulking, monster database nourished by a strange team in lab coats building Frankenstein’s monster. What you need is a plurality of sources and technologies combined pragmatically to achieve pragmatically achievable ends.
Unfortunately, the industry being what it is, there is the invariable push to pigeonhole what a CMDB is, cordon off a market around it, create a precious list of criteria that all CMDBs “must have,” and pretty soon we’re back to Frankenstein lurking in the basement. Successful CMDB System deployments are not about “building CMDBs.” They’re about leveraging an enabling set of technologies inalterably linked in purpose and design to support whatever it is they’re enabling – from service impact management to asset management to change and configuration management, to IT governance and risk, etc.
So what does this have to do with the NOC? I would postulate the following:
• Network Operations feels left out because most vendor offerings remain weak in support for network infrastructure and many are delinquent in integrating network discovery and topology – which was arguably the CMDB System of old -- where a “common pane of glass” was achieved across all infrastructure interdependencies.
• Partly because of the above, Network Operations can rightfully claim that “we have our own tools” for doing this – since the Data Center is driving most of the efforts so far with less network-friendly tools.
• Network Operations has long suffered from being blamed for problems to do with the applications and data center devices, and this doesn’t tend to make its professionals warm up to a more transparent, shared universe of responsibility (a big mistake but one that’s understandable).
• Most of the world still doesn’t grasp the “real-time” component of CMDB Systems, which makes it easy for Network Operations to claim that its “war room” should remain on separate turf.
In my next column (in two weeks), I’ll share some of the testimonies from specific network-centric CMDB deployments in terms of drivers, deployments and other perspectives, as well as a few comments from other deployments that may shed some light on why the NOC tends to get left behind. In the meantime, I would very much like to hear from you – all your comments and perspective are welcome – so please e-mail me.
Oh, and as for the question posed in today’s headline, the answer is “yes” (if you haven’t guessed already). But this doesn’t mean going off and building your own Frankenstein. It means starting to think how you can leverage the tools you’ve got, and put pressure on your vendor suppliers, to participate in a better fabric for sharing data across domains - or, in other words, participating in a CMDB System.