At the moment, the golden goose of the IT management world is the CMDB. Thus, as someone who is addicted to covering and thinking about systems management (I haven’t found the cure yet, though identity is getting close now-a-days), CMDB and I are always passing each other in the hall. We even get coffee from time to time. He like to lunch at much more pricey places than I — that guy who just stand there the whole time freaks me out! — so we draw the line there.
Along those lines, here are some disconnected mental notes on my friend CMDB:
REST/ATOM is all about a standard and simple (!) API for creating, updating, reading, and deleting “resources” described by URLs. What’s a Configuration Item but a resource that’s always being created, updated, read, and, maybe, deleted. There’s relationships between CI’s as well which, my gosh, the REST world having coming out their eyeballs from the public web, which has — what? — 60 different answers for describing relationships, a handful of which have even been road tested over years and at scale.
More reasons:
Why come up with some horky WS-*/SOAP spec when you could just define the URL (ok, ok, “URI”…whatever) addressing of CI’s, how relationships are expressed, and then slap an ATOM interface on top of it?
More importantly, REST and ATOM are simple approaches to complex problems that developers actually like.
(Hint: REST and ATOM are web services, just not Web Services.)
With a REST/ATOM interface, the CMDB would be dead-easy to integrate with other systems, not just other CMDBs. Metcalf’s Law with your coffee, sir?
Sounds like a standard approach that’s completely doable and effective to me.
To that point, isn’t the CMDB federation group (they don’t have an official title, do they?) more about CMDB interoperation than federation? I get that you need interoperation to enable federation, but actually cracking the nut of CMDB interoperation (standardizing the interfaces and somehow coming up a data model or semantics packaging) seems like the real and most difficult effort.
Low Barriers to Entry Needed
To that point, it seems like having proprietary interfaces and data models is what’s holding CMDB’s back from wider and easier use. SQL made RDBMS “work,” in this sense, and having an open standard for CMDBs should have a similar effect.
Now, for those same reasons I’m also suspicious of how much vendors charge for CMDBs. Wanting to maximize profits on a roach motel aside (go-go revenue!), a model where CMDBs are given away — or (gasp!) open source — to bring in revenue for the supporting tools seems much more reasonable for spreading and developing the CMDB at this point (selling scale and whiz-bang a la Oracle might fit later). But hey, I’m open-biased.
Put another way: do enterprises still want to subsidize the development of core technologies by paying for “1.0″ products? The implication being that 1.0 products don’t, ahem, “work” so well and the customer is more doing a fancy dance to fund development than buying a finished product. See Oracle’s early history with the US Navy, CIA, and other large organizations.
Another nail: really, we know the value in a CMDB is setting up, “configuring,” and hooking it into an enterprise’s process and IT. It’s a services sale centered around a chunk of software. Gating that software with license sales just limits the number of much higher paying service engagements the vendor and SIs can do.
Skills as CIs
Do the skills required to maintain IT belong in the the CMDB? Peter points out a discussion in an IMS list about a lack of skill and (my re-wording) enterprises not treating that skill as mission critical to the business. It’s a wetware boundary problem. Sounds like a CI to me — A “Wet CI”? — but then that means hooking up to identity provisioning and de-provisioning.
It seems kind of ridiculous, but comprehensive.
(Thanks to Chip for kicking the rust off my mental CMDB gears yesterday.)
Disclaimer: several companies in the “CMDB space” are RedMonk clients: BMC, IBM, Microsoft, and probably others who’d benefit from the spread of CMDBs.
Previous Topic
