CMDB, if you didn’t know, stands for Configuration Management Database. It is the term that the system management vendors (IBM, CA, HP, BMC, EMC, etc.) have settled upon to describe the repository of information about IT Assets that every organization needs to keep and which, it is quite clear, very few organizations do keep accurately. Let’s cut to the chase…

What is an IT Asset?

Once upon a time, a long time ago, when Dinosaurs roamed the data centers, companies actually knew what IT assets they had. They had mainframes and those mainframe were damn expensive and they were closely controlled so that every dollar of processing value could be squeezed out of them. Every program that ran was known, all workloads were thoroughly understood and computer operations ran smoothly. The IT assets were the computers, the software that ran on those computers and the data that was processed

Rather than write a history of why this is no longer the case, I’ll just concatenate the litany of influences that destroyed the control that IT departments once had:

New OSes, New platforms, Distributed and departmental computing circumventing the data center, PC proliferation and particularly PC LANs running business applications, the continuous collapse in the cost of most hardware and software, the escalation in the number of applications in use, the Internet, intranets, silo based computing, frequent changes to and the rapid growth of computer networks, etc.

BDNA and the CMDB

The idea that an organization should keep an inventory of all its software and hardware is neither radical nor foolish. It’s obviously sensible and ultimately necessary. What has happened in most organizations is that the activity of keeping such an inventory has become  fragmented and manual. The technicians that manage the network, for example, may have a record of all the network devices and the computer servers connected to them. The database team will probably know all the instances of each kind of database. In-house applications will doubtless be documented. Hardware maps will exist. Much of the information will probably be held in a variety of spreadsheets.

But when you introduce a CMDB into such an environment to record and maintain IT Asset information, a whole series of problems emerge. Who will take responsibility for integrating all the disparate data sources? Who will rationalize conflicting metadata? (Indeed how will the metadata problem be handled?) Who will enter the data and keep it current? At what point in the various data center change processes will new CMDB data be captured? I could go on….

A CMDB, introduced just because there’s a need for one, isn’t going to have much success for the same reason that software development repositories never had much success. On it’s own it doesn’t actually deliver any benefit. It’s the applications that run from the CMDB that deliver the benefit - whether they’re using the data to implement support policies or gather usage information to ensure that software licenses are not being violated.

BDNA is a vendor that has been having some success in this general area and it is important to understand why. BDNA doesn’t provide a CMDB, it provides an asset discovery capability, called Insight (current on release 5.0). Basically it’s an appliance that sits on the network and listens to it. You only need to feed it with the range of IP addresses of devices on the network. It then  listens in and quickly builds up a real-time inventory of the whole network, matching it with a database of reference information to fill in model numbers, version numbers, release dates and other such important details. It builds its own database.

Asset discover products aren’t new either, by the way, I’ve seen a number of them in recent years, and some of them have had problems gaining traction. But BDNA isn’t really selling asset discovery. It’s selling an IT Procurement capability, an IT Security capability and an IT Operations Management capability. Asset discovery is how BDNA’s Insight gets the information to feed these applications - and it can feed that data directly into a CMDB, if that’s what you want.

Insight gathers and maintains a real-time database which it uses for:

• IT Procurement: It builds an accurate inventory of all software assets, identifying all application and database instances, which provide the information base for software procurement negotiations. This is application is pretty much guaranteed to pay for itself if you don’t have an accurate inventory of the software you use.
• IT Security: Insight identifies whether security software is deployed according to company policy, records service pack levels, patches and releases, for checking against approved release levels, and identifies unsupported OSes or other unsupported or unapproved software.
• Operations Management: Insight assists in cost management by tracking licenses (OS and App propagation and also Virtual Machine propagation). The VM capability here is likely to grow in importance. Additonally, it can populate a CMDB, which may be used in other applications.

In my view, the CMDB is the right answer to many issues that plague data center management, but it’s only the right answer if you can gather and maintain IT Asset information reliably. BDNA’s contribution is that it provides a capability that delivers business value and also leads in that direction.

Some system management vendors partner with BDNA specifically to help in implementing their CMDB products. There are still metadata issues and federation issues that need to be resolved in implementing the CMDB, but the BDNA approach at least makes a CMDB viable.