CMDB in the NOC: Is it time yet?

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.”)

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

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.