Skip to content

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 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: , , , , , , , , , ,

Categories: Enterprise Software, Open Source, Systems Management.

Comment Feed

9 Responses

  1. I am a partisan in this discussion, being from CA and a member of the CMDB Federation Working Group technical committee (we do have a name!), but I want to point out that the CMDBf spec and work on language standards like SML pave the way toward a level of standardization that will make an open source CMDB make sense. Believe it or not, I think an open source CMDB is a great idea, but you point out many problems that hold back an open source source implementation as much as closed source. Without widely accepted models of interfaces, CIs, and transactions, an open source CMDB is no easier to integrate or federate than any proprietary product. So right now, those of us from the vendors who are slogging it out in the trenches, building the standards that will make CMDBs easier to implement are doing a service to open source as well as proprietary products. You can see some of my perspective on this in my blog, Marv Waschke

    Marv WaschkeNovember 28, 2007 @ 5:48 am
  2. Thanks for the comment and link (you can bet I’ll subscribe), Marv. I agree with you: the standards are the key. My thinking is that having shipping code with the standard – rather than just having the standard itself – is vital for adoption, esp. in the IT management area. That said, I don’t know what the CMDBf’s plans for the reference implementations or other “running code” along those lines. Out of curiosity: are there some?

  3. It is too early to give you a solid answer to your question, but let me point out that for a vendor like CA, working on a standard is an investment and we will do what we can to get a return on that investment. If we don’t adopt it ourselves, our ROI is gone. If the CMDBf specification is not widely adopted, our ROI is gone.

    Would an open source reference implementation help? Thinking back on my own experience as a developer, without the open source reference implementation of the SNMP trap code, (was it someone from Stanford who wrote that?) I am sure I would not have been nearly as eager to put automatically generated incidents into the service desk product I was working on at the time, and I don’t think SNMP would have become the ubiquitous standard it is today.

    So, would I like to see an open source reference implementation of the CMDBf spec? You are darn tootin’ I would. I can’t go beyond my own opinion, but you know for yourself that no one likes to lose ROI…

    Along those lines, tell us more about what you would like to see in a reference implementation. What form would you like it to take? How would you like to see it published? Never can tell who might pay attention.

    Marv WaschkeNovember 29, 2007 @ 1:01 pm
  4. Thanks for the re-reply, Marv. Ideally, what I’d like to see in an open source ref. impl. is a project that coincided with the development of the spec as much as possible. Why during? Because I’d rather see coders encounter errors in coding to the spec and feed that back into the spec as much as possible. Also, it’d be good to have the whole process of developing the code in the open for others to look at when doing their own implementation – as you nicely reference back to the SNMP impl of yore.

    Ideally, the ref. impl. would be production ready – if not in the fine print, then in the code at least. Also, it’d be key for it to be very permissively licensed, under the BSD, Apache, or like so that people could yank the code to use on their own or start for their own projects, open or closed source.

    That’s just a quick, off the top of my head response. I’m of course happy to think out-loud more 😉

    Additionally, you might consider coming down to barcampESM this Jan in Austin, TX to talk with a wider audience.

  5. htt://
    This is a simple cmdb writen in java.

    jinxfeiDecember 8, 2007 @ 9:10 pm
    Big CMDB-Tool written in PHP

  7. You should add to the existing ones as it is currently the best open source CMDB

Continuing the Discussion

  1. […] People over Process: An Open Source CMDB […]