![\"CMDB](\"http:\/\/farm1.static.flickr.com\/131\/398876934_548e99f7e0.jpg\")
<\/a><\/p>\nHave you seen the CMDB Federation white-paper<\/a> (from these folks<\/a>)? Not too shabby, esp. since it’s just 10 pages; take the Skeptic’s advice as a bracer<\/a>. My main thought: for those interfaces get REST<\/a> in\/on there! Why not ATOM<\/a> too?<\/p>\n 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<\/a> 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<\/i> and at scale<\/i>.<\/p>\n More reasons:<\/p>\n Sounds like a standard approach that’s completely doable and effective to me.<\/p>\n So: any CMDB geeks want a connect to some REST\/ATOM geeks? If RedMonk is a lonely connector between any two groups<\/a>, it’s those!<\/p>\n I know Mr. Twiggs<\/a> would get giddy.<\/p>\n To that point, isn’t the CMDB federation group<\/a> (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<\/i> and most difficult effort.<\/p>\n To that<\/i> point, it seems like having proprietary interfaces and data models is what’s holding CMDB’s back from wider and easier<\/i> use. SQL made<\/i> RDBMS “work,” in this sense, and having an open standard for CMDBs should have a similar effect.<\/p>\n 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<\/i> (selling scale and whiz-bang a la Oracle might fit later). But hey, I’m open-biased.<\/p>\n Put another way: do enterprises still want to subsidize the development<\/i> 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<\/a>.<\/p>\n 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.<\/p>\n Do the skills required to maintain IT belong in the the CMDB? Peter points out a discussion in an IMS list<\/a> 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<\/a>. Sounds like a CI to me — A “Wet CI”? — but then that means hooking up to identity provisioning and de-provisioning.<\/p>\n It seems kind of ridiculous, but comprehensive.<\/p>\n\n
CMDB
Federation<\/s> Interop<\/h2>\nLow Barriers to Entry Needed<\/h2>\n<\/p>\n
Skills as CIs<\/h2>\n