An Open Source CMDB

“On a moment’s notice I can list every server we have that touches credit card data, and people know they can trust that information,” he says. “The biggest [hurdle] then and still is getting people to follow the process. But with results, I got a commitment from management, and then other groups such as engineering followed, and the data stays good.” —“University taps ITIL to build open source CMDB”

At the heart of big IT management think now-a-days is the Configuration Management Database, or CMDB. The meaning of CMDB ranges from basic, to pragmatic, to vapor-ware. The idea of a CMDB is to catalog and track every thing, process, and relationships between those two. Words like “Configuration Item,” “Asset,” and “Service” are used. A more basic notion is “Asset Management” which simply tracks all the “assets” IT cares about.

For me, all the data-sheets and fancy explanations are sort of meaningless: a CMDB is just a place to store all the junk the IT department cares about. This loose distinction separates from MDM efforts which seek to catalog everything a company cares about. Of course, IT-types with a hankering for bigger britches would content with that nuance. Indeed, sometime soon, I reckon we’ll see CMDB people get in a turf war with MDM people industry-wide, but that’s a story for another time.

The idea of a CMDB is enterprise software at it’s finest: it’s middleware without an implicit user-interface, has a wide-scope, means something slightly different to each user and seller, and has yet to be commoditized into freeness and ubiquity.

And there-in lies something I’ve been thinking about since attended IBM’s Software Analyst Summit a few weeks ago: one of the Big 4 needs to open source their CMDB soon.

Quick Reasons Why

In summary, the reasons to do this are:

• The model expressed in CMDBs and the accompanying data standard would spread like wild-fire if community-managed correctly. There’s no good, widely used model for IT stuff at the moment. Instead we have a bunch of islands of standard alliance all based on overly-wrought SOAP-bound XML. A standard with a runtime – the open source CMDB – would have the best chance so far to finally dethrone King SNMP, the only widely successful standard for modeling IT stuff.
• With that model spread, the higher-level, higher-value tools sold by which ever vendor did it would work better. All those fancy dashboards, ITIL-driven workflow, automation, and everything else hinge on getting the boring details of plumbing done correctly, and having a widely used model instead of having to adapt to every weird computational asset out there would save a lot of time and improve quality.
• Disrupt the other 3.BMC, for one, would freak-out if there was a threat to it’s Remedy ARS based CMDB. They’d spin up all sorts of “tiger teams” (or whatever they call them). Same for HP probably, CA, and IBM.

(Related, see my short note and the resulting reader comments on the CMDB Federation standard effort.)

Existing Open Source CMDB

CMDBs currently make a lot of money for the commercial companies that sell them. I know of two open source efforts in the CMDB area:

• Whatever they’re up to over at CMDB.info. I’m kinda of confused about what’s going on there, but it looks like a strapping together of a several open source projects to CMDB’ize the enterprise. (I don’t mean to sound dismissive: I’m just being sort of lazy with the hope that someone will help fill me in via comments or email.)
• Zenoss’ “First Commercial Open Source CMDB.” Zenoss is a RedMonk client, so you can take the bias as you will, but they seem to always “get” the idea of model-driven IT management which, really, is a big part o what CMDB-think is all about: if we could just model and keep track of the changing model of IT, we could manage it better.
• Others which I’ve no doubt missed. There are kinda-CMDB projects like ZipTie that sort of fit in there, but not in the fully-dressed CMDB sense.

An open source CMDB from one of the Big 4 would ostensibly compete with the above. But, I think that’d actually be advantageous for all of the parties, not to mention the customers out there who’d benefit from more open source choices.

CMDB Advantage: One Model of IT Stuff

The advantages a CMDB (theoretically) brings an IT management platform are:

• Establishing a “model” and vocabulary for describing all the junk in your IT environment. There’re always numerous ways and software products to catalog all the computers, software, and ways those computers and software are used (“services”). Instead of having 4 different products you use to manage you IT, each with it’s own way of cataloging the your IT stuff (that is, it’s own way of “modeling”), why now just have one that they all use? Or, at the very least, why not just have one view on all that mess that you use?
• You can even get all 2.0 and say that by jamming things like network cards, virtual machines, and “service that allows outside buyers to submit change to previously submitted purchase order” into pre-definied “model” or “labels” allows you to attach some semantics to the catalogs of data. I’m being very basic and loose in my use of “semantic” here: but, simply adding a user-divined label (or “tag”) to something ads a huge degree of semantics that were previously not there.
• Ideally, once you have all of your IT stuff “normalized” into one model, it’s easier for all your different IT management products to interact with and use that information. That is, a CMDB should help with integration up, down, right, and left along the stack. For example: your monitoring product keeps the status of all your IT stuff up to date in the CMDB; then your dashboard product pulls that information into it’s fancy views; and your synthetic event generation product pulls information from the CMDB to figure out if some critical process is working properly based on the individual status of all it’s components (the Oracle database that stores all the package UPC codes is up and responding quickly, etc.). Ideally, having one, centralized way of modeling IT stuff makes integrating all your tools together easier, if not possible.

Now, CMDBs get played up as a lot more than simply a “central” point where IT stuff is modeled. But, really, that’s all they are: just a big, virtual file-cabinent to store stuff in. Things get complicated-sounding when you start modeling relationships as part of that “IT stuff,” and get seemingly bonkers when you start putting things like “business processes” or “services” in there. But just stick your mind on it being a giant filing cabinet where the different folders and pages have strings in-between then that express relationships.

That sounds like a mess in meat-space, but I assure you, it’s the thing of programmers’ dreams in cyber-space.

Open vs. Closed

From the conversations I’ve had with numerous people, the problem with their realizing this CMDB advantage comes from the closed nature of developing CMDBs. There is no standard for how things are modeling in CMDBs now – each vendor is free to do whatever they want. Behind closed doors that scheme for coming up with something as central and universal as a CMDB spells disaster. Think of how silly the Oracle DB, or any database, would be if it didn’t operate off the SQL standard. It’d be a nice database – maybe a nice, super-fun one like BerkelyDB – but it wouldn’t be as widely useful as an SQL-based relational database.

The same applies for CMDBs: as long as the underlying data-model for CMDBs is developed behind closed doors, by single-entity teams, they’ll be less than ideal approaches.

Part of the advantage of having a open source CMDB, then, is to get around that problem more quickly than a long, decade-plus long siege of ubiquity would handle solve the problem.

That’s a lot of faith in open source, sure. But when it comes to a part of any software stack that’s intended to be used by every piece of software instead of just software from one vendor, I’ll go with open source over closed source all the time.

Then What?

So, where’s the money? As noted above in the quick summary, the money is in doing something with the (better) data in the (now) standardized CMDB. All of the fancy, high-level “service management” stuff you see from IT management vendors relies on having accurate data from the bare-metal to the PDF reports. Garbage in at the bottom with monitoring means garbage out at the top in dashboards.

As a side-note, consider how poorly most IT management companies treat the monitoring people: next time you talk with them, ask them how much they spend on basic monitoring vs. “service management” and dashboards. (It’s a snarky point, but it’s a good discussion starter.)

All this high-level stuff is actually valuable if it makes sense of all the “low-level” monitoring stuff. Imagine this scenario: you’re a mid-level (or high-level, don’t really matter) manager in charge of some chunk of IT. You have no idea how that IT works, but you know it makes your company. If it went out, you’d be in big trouble. You get all sorts of reports with red and green lights every day. You can’t make sense of the “health” of the 50 servers and 15,000 “parameters” you’re in charge of. You always have to call together a meeting of people and ask them “OK, so what they hell do we now?”

That is, you need to use all that fancy, expensive IT management stuff to make decisions about what to do next, esp. when things are going wrong. You don’t need a bunch of facts you need conclusions: “Return process is 5 minutes behind desired time to completion: click here to add more caching servers to the cluster.”

Now, that kinds of stuff is totally pie-in-the-sky, like rocket-cars. But, hey, maybe you can’t have a rocket-car, but we’ve got really expensive personal airplanes. There’s gotta be a market for that.

Yanking out of the metaphor-hole, the point is: an open source CMDB would have a better chance of providing the clean, correct data, from as many sources as possible, delivered more quickly to the industry than a closed source one.

And, like I said, it’d really piss of the other other 3 of the Big 4.

You could imagine that others like Sun, Symantec, and others could pull it off too. Sun is always a weird opportunity in IT management: if they could bust out of the perception that they’re Solaris-centric and deliver something as attention-grabbing and low-barries as Spiceworks and Solarwinds, they’d seem to have the technology and open source gumption to do it.

Sure, others could hijack that value. But that’s sort of the point. The more ISVs and others using a CMDB, the more standard and reliable it becomes, and the better positioned it is to serve as a foundation for higher value, like customized reporting, dashboards, event generation/tracking, or whatever tool you use to make decisions about what to do with your IT to make your company more money.

If you’re interested in new approaches to CMDB’s, you’ll probably also like this overview and demo of Managed Object’s myCMDB – it’s like Web 2.0 applied to IT Management.

Disclaimer: Zenoss, IBM, BMC, Sun, Spiceworks, and CA are clients.

Technorati Tags: cmdb, bmc, ibm, hp, ca, dashboards, conclusions, zenoss, cmdbf, modeling, spiceworks