The CMDB Federation releases its federation specification for public review

The CMDB Federation has released "version 0.95" draft specification of the standard for federation (read: interoperability) between CMDBs and similar operational software. This specification will make quite an impact on the IT operations software market once it is finished... but it isn't yet, not by a long way.

Read it here, or rather: look at it. Much of it is geek-speak UML. There are still gaps in the document. There is plenty more work to be done before it begins the path to ratification: "This document is an initial draft still under internal review.".

But at least something is happening, and there has been quite a lot of work to get to this point, including actual interoperability testing between the vendors.

Some time in 2008 (2009?) this thing will finally emerge from the swamp as a fully-fledged standard. The vendors will all swear fealty to it. Hopefully most of them will be well placed to release versions of it pretty quickly. Does somebody want to run a sweepstake on how many of them will find a way to make this an extra-cost option?

When that fine day dawns we'll finally have the ability to build heterogeneous IT management environments. The IT Swami predicts that this will give a tremendous boost to open source tools such as Zenoss. They will be able to displace vendor tools one bite at a time instead of a revolutionary overturning, thus making them far more attractive to companies who want to ease carefully into open source. No wonder there is no great rush to finish this.



Hi Skeptic,

This "specification" is a good example of the vendors way of thinking. We do not need another definition of a query (or of query against a CMDB), but a general definition of what they want to store in their CMDBs and what the information means would be more usefull. Why do the techies always reinvent wheels? And why do they never come up with a round one?

So do not expect this "standard" to help boost the open source community much. The most positive part is the amount of pages spent about identifying the CIs. To my experiance, that really is the most difficult part of getting to "CMDB" environments to be meaningfully connected. And why is this difficult? Because process plays a part and vendors can not be bothered with process ("Identifier" MAC address is changed when I swap a defective NW Card. "Identifier" PC Name is outliving my server because I use the same name on an other CI, etc.). So I hope people start to think a little bit more about the way they identify their CIs (and identify what they mean when talking about the CI, the physical box (Serial # 12345), the OS instance (called or maybe the NW Entity (MAC ab:cd:ef...).

I know your position on CMDB, but I still believe (and have seen and build the environment and process) that a move towards a CMDB is usefull (you may never really reach the final goal, but walking that road brings you forward). As long as you know that you can not buy a CMDB of the shelves, you have to walk there yourself.

CMDBf spec 0.95

I am a member of the CMDBf technical committee, and I sympathize on these points. I can see why the CMDBf spec disappoints you; it does seem kind of silly that the committee was off reinventing query definitions instead of tackling some of the obstacles to federation like reconciling divergent CI taxonomies and nailing down CI identities.

Nevertheless, I am not disappointed and I would like to explain why.

You have to appreciate where the authors of the spec come from. Our focus is interoperability. Before you can begin to tackle what I like to call ‘content issues,’ you have to deal with the structural issues, which is the target of this version of the spec.

For example, most people with CMDB experience agree with you that working out identifying properties and reconciling them is one of the hardest problems in CMDB practice implementation, but without defined and agreed upon architectural structures and interfaces, you can’t build an interoperable environment where you can even test reconciliation, let alone solve the problem of reconciliation. This first spec is not meant to solve all the problems of federated CMDB implementation, but it is intended to take a necessary first step: an interoperable environment where the problems can be solved.

The spec and whitepaper hint that some of the ‘content problems’ are in the CMDBf scope, and if all goes well, there will be progress there as time goes on.

I blog on the CMDBf and other IT topics at

First Centralization, then Federation and next Virtualization...


I too welcome any progress on this topic. In your workings is there any thought to the Virtualization wave hitting the market right now? The challenges of Centralization (logically) and Federation pale into insignificance when the big 'V' hits.... Ian

Aaahh Virtualised servers

The move towards virtual servers has been a very interesting topic indeed. Lets start on a positive note. I have been following a few of the skeptic blogs over the past month or two after a break of quite a few months. Just so happens I've been busy building virtual images of some open source CMDB tools. And besides using the VM technology in enterprise as an Ops Management Consultant, I had actually never had my hands on it. And its great. I have been able to build these VM Guests which can be downloaded and run up in 5 minutes. To sit down and load all of this software under a linux command line, usually took me anywhere from 4 to 8 days. So some of the benefits are huge and competing technologies about software virtualisation are now coming on the scene. IE: Under your Win systems you can deliver an app in seconds as it runs all of its requirements in a virtual shell, dll's and propritory stuff.
I would be interested to know what was discussed about VM's when the CMDBf Specs were being defined. BTW , I did have a quick look and it seems like a great first release. One of the most difficult things to do is discover what is a virtual and what is a physical server on your network if you havent factored that into your host names, so the vendors will have fun with that.
Maybe VM will get on the roundabout as well, they do have a reasonable monitoring and management interface to the operational stuff of the VM Farm. Just to clarify a few points, I think Virtualisation is great if you architect your solutions to suit. When you need physical tin nothing else will do the job. VM is great for dev, test regions, and this can save substaintial costs both in terms of development cycles / build deployments as well as the savings for not hosting the physical tin. Under a managed service arrangement / outsourced arrangement it will most likely cost you just as much.(Vm vs Physical)
We should not get too caught up on the complexities of centralisation, federation, or vitualisation, its really not that complex, now we have some idea of where everyone is heading in terms of requirements. I wont go into the subject here but if anyone is tempted to take a look at the toolset the download is available at It meets much of the specified criteria and I'm sure the rest can be factored in, all the important base elements are there. The unique identification may be a bit of an issue, but hopefully it wont be too hard. An alignment of 3 or 4 unique criteria can be used to verify a previously discovered device and most of that is in there.

Cheers Brendan

Virtualization and CMDB federation

VMs are hot. No question about it. Virtualization is a frequent topic in industry conversations. In the CMDBf, virtualization has come up occasionally in use case discussions, usually as a corner or edge case, but it is actually more in data modeling territory, which the CMDBf 0.95 spec intentionally does not address.

From my point of view, the challenge in a CMDB for virtualization is the dynamic nature of the beast. Generally, I think you need to distinguish between configuration and operational state. Configuration is the relatively static side of a CI: set it, but don’t forget it. Operational state is what changes as a CI does its job. Generally, a CMDB is designed to manage configuration; managing operational state is for monitoring tools. Crisp, this distinction is not. CMDB users often want real-time status and monitors display configuration all the time. Virtualization blurs the distinction even more because you could say that the configuration of the VM is an operational status that changes as rapidly as any conventional operational status. Getting the right balance in a usable, scalable, and performant system is not easy.

Read my blog

Virtualization & CMDBf

My $0.02:

Virtualization is simply an added wrinkle in the CMDB's data structure; in particular, it becomes necessary to disambiguate the concepts of "server" (as a running OS instance) and "machine" (the thing that came in on a forklift from the loading dock). They require a many to many; a "server" may run on multiple "machines" (e.g. in a VMWare cluster) and of course a "machine" may host many "servers." And as Marv mentions, the CMDBf spec has not gotten into that level of specificity.

An integration (federaration) with the VM element management (e.g. VMWare ESX) becomes necessary, due to the more dynamic nature of virtual machines. However, in a governed IT environment, those virtualized servers are still critical CIs. Any operating system instance is a particularly powerful and potentially hazardous beast, given its general computing capabilities. They require strict governance in terms of who requested them and what they are being used for, and ensuring that their patches are up to date (just as physical servers do).

If one is relying on application teams to document "application to host" dependencies, the VM instance becomes their primary point of contact; the physical server is no longer visible to them.

I'm completely confused as to how ZenOSS and CMDBf have anything to do with each other. CMDBf is an interoperability spec. One might use a variety of open source tools in building a CMDBf-compliant system. Yes, one could then run one's solution in a virtualized environment. But this is not a groundbreaking idea, nor is there a particular advantage in the combination of CMDBf and virtualization.


Virtualization: Any Modelling Suggestions?

Very interesting discussion here... Charlie, I'm wondering how to model the "VM element management" that you mention. Ok, you have the server/machine relationship, but what about a cluster-like concept like an ESX-Farm. As you state in your paper, one machine may host multiple servers, and one server may be hosted by multiple machines. Should we not be able to materialize this concept into our model more specifically? A VM (server) not only depends on a machine, but also on a cluster of machines(e.g. ESX Farm). When the cluster goes down, so does the server running on it. The actual machine can keep on running. Not so sure if I made my point clear here ;-)

Any suggestions on how to model this dependency?

Modelling virtual machines, clusters etc.

It depends on why you want it in the cmdb, ie. to provide a mechanism to control change, a reference point for ownership, licencing etc. So assuming that we are loosely wanting something to support service processes I suggest you apply the following heirarchy;


parent of

Virtual infrastructure - Cluster, virtual server, LPAR, partition etc.

parent of

Physical infrastructure/hardware platform - Chassis, blade, processor etc.

Within each category you can have parent/child - chassis has a number of blades, each has a number of VMs.

I've just modelled a large email environment which has clustered mailboxes, running on virtual nodes, supported by a number of blade server with active/passive status. For the purposes of controlling change they were treated as separate controlled CIs. We didn't go into modelling the storage sub-systems etc. as it had no value. We linked the CMDB database to a visualisation tool to show the dependencies as a map to make it easier for non-technical teams to understand the linkages

The more complicated you make it, the fewer the people that can use it.


Zenoss and CMDBf

Charlie- Quite right, the two have nothing to do with each other in terms of alignment in their current state. Skeptic's original question was more whether the release of the spec would boost interest in Zenoss and other open source competitors because Zenoss (and Centreon / Oreon / Nagios) have some cool features, eg: host to application to service mapping capabilities. It's a far way from meeting the spec but it doesnt mean it cant be developed along that path. The data modelling was something I was very interested to review, and I agree a data modelling standard is where the spec should be headed, although I'm sure there would be a claim from someone that they hold a copyright on the model. Virtualisation is also irrelevant, solutions need to be designed to be fit for purpose. Overall the availability of open source software running as VM's has made open source deployment for organisation a much more viable proposition but they should also be wary that they have not been architectured for any specific environment. As for tracking them in a CMDB, they are in a farm situation and need to be managed with some additional considerations, but yes its still a CI. Sorry if I threw you offtrack somewhere.




OK - helpful - can you post a specific pointer to where the host/app/service mapping capabilities are documented for any of these products?

Of course, it's still all about the process:

-who does that mapping?
-at what point in the service lifecycle?
-is there the necessary governance in place to enforce master data management? (that is, one authoritative list of applications/services; not multiple overlapping concepts owned by a variety of silos...) my #1 concern as a CMDB practitioner...

Charles T. Betz

A specific pointer, hhmmm

Well its a normal expectation that I would be able to provide that, unfortunately thats one area where open source software will let you down. I can direct you to a vm guest/appliance of the tools. Downloads

The CMDB has to serve many masters, and I'm sure there will be those that disagree with the concepts of the CMDBf overview. The concepts are fairly sound, but as you've highlighted, tread carefully, a CMDB at enterprise level is a very detailed entity. There are so many ways for the data and functionality to be modelled, its dependant upon the master making the request. The vendor offerings will be under pressure to cover all areas of process meanwhile smaller specialists have already chipped away at their foundation. Current organisation is implementing a commercial software metering tool for a MetaFrame Farm. Reasonable expectation that a CMDB can provide software metering of some sort.

Under open source code can be easily modified to suit an alternate purpose. Open source has a long way to go before any compliant CMDB integration can be achieved, but all of the foundation components are readily available, just not well documented.

This is something I've been looking into for sometime. Can an automated discovery tool map an infrastructure CI to a service CI. At this stage, there is no automated discovery of the service and the mapping is a manual process of setting up the relationship structures, but all the interfaces are quite good. Vendors state that they provide the agentless discovery functionality but I doubt the accuracy.

That, Documentation and the Data Model are my next worthy causes.


central integrated CMDB will no longer be a proprietary lock-in

You guys may have gathered by now that i am more interested in concepts than specifics. I see CMDBf as the birth of a standard protocol for systems manageemnt tools to share their configuration and, potentially, status. In this sense it takes us along the road to plug-and-play systems management, and therefore opens the door for open source tools to replace high-cost vendors in each site by stealth, by evolution, one bite at a time, instead of requiring a revolutionary replacement.

I wasn't thinking specifically of open source tools taking over the CMDB functionality per se, and I haven't even looked at their capabilities in that area (cmdbmaverick has). But the release of a CMDBf standard would allow open source tools to plug in to a CMDB in order to get the configuration data, and in return to provide status monitoring, inventory, service level reporting, capacity history, auto-discovery... (The same is of course true for competitors: it will open up the market to greater competition between vendors)

Having a central integrated CMDB will no longer be a proprietary lock-in for the vendors - that's my point.

A worthy goal - but do angels fear to tread?

Interoperability is a worthy goal. But Here There Be Dragons. I've watched UML through its ups and downs, as well as other specs attempting to standardize tricky technical ontologies. I think that the best we will be able to hope for is a two-tiered solution in which a base spec is declared and then refined with interpretations and profiles. As a computer scientist friend of mine pointed out, all UML standardizes is syntax - it does not and cannot standardize semantics effectively. Because of this, UML diagrams can be (and are) interpreted and mis-interpreted in a variety of ways. The CMDB problem is no different, especially when we get into logical concepts such as Application, Process, Dependency, and Service.

Let me give you a concrete example from UML. Let's say I have two teams doing information modeling with class diagrams, information modeling that will drive the creation of logical and physical data models. One team opts to link classes with the Association line, the other team opts for the Dependency line. There is no UML guidance on this; both are syntactically valid ways to link Classes. I now can "exchange" these models between the two teams, but it will be immediately obvious on both sides that there has been a semantic mismatch.

Here is a hypothetical example from CMDBf. Let's say that they define a Service type. Obviously, Services may depend on other Services and contain other Services. It is basic information theory to allow directed and undirected graphs, so a CI can both "contain" and "depend on" others, and it's a safe bet that CMDBf will at least define a 1:M tree connector and an M:N network connector on the base CI type. Back to the two teams. They are modeling service dependencies, and while one team models them as a network, the other team models them as a tree except where they are compelled to use the network connector to avoid dual parentage. Again, a semantic issue that cannot be syntactically enforced. There are ways around this, starting with this analysis I did a long time ago. But the point is that in problem spaces of this nature, interoperability will always be hard.

I think we will see a basic data management and interchange capability, but actually getting tools to interoperate using CMDBf will always result in some additional transformation rules necessary to reconcile the impedance mismatches.

Charles T. Betz



You are right on target re: UML. Indeed, it's not unique to UML, but given the widespread adoption over the years, the problem is more acute. Way back when (too long, I think) when I was runnning OO design teams, I had my teams use Shlaer-Mellor Recursive Design for our projects. For those that care, this was a ways prior to the release of the first draft of UML. At this point in history all of the methodologists were debating each other and vying for mindshare. Anyway, while RD had it's own set of notations, that wasn't the power of it. The real power was in two key points:
1. There were a defined set of work products that you could expect to produce for any project
2. There were rules that governed the interpretation of the models

If you didn't have #2, #1 was worthless (given the nature of the RD approach). The rules for interpretation helped guarantee that two practicioners could view the same model and interpret it in the same way. Unfortunately, many less mature developers would view this as a "constraint to their creativity", rather than as "enhancing their ability to communicate effectively".

In the end, with the adoption of UML by tools vendors, the S-M notation fell off, but the rules for interpretation were just as powerfully applied to UML. From my perspective, the closest that anyone has gotten to bringing the rigor of S-M to UML since then was Bruce Douglass in his book "Real Time UML". It's a worthwhile read and there are lots of goodies to extract and use, even if you aren't interested in doing OO development for real time systems. The thinking behind how the phases of development are linked and how rules for interpretation are applied can readily cross practice boundaries.

Great seeing you in Charlotte!

Data modeling?


re: 'data modeling territory, which the CMDBf 0.95 spec intentionally does not address.'

As you may be aware I've been somewhat bemused by the CDMBf efforts, because the underpinnings (while important) are hardly the meat of the matter. What is important, is the data model, and the degree of semantic specificity (strong typing, if you will) that will be attempted.

I can make data models interoperate through a variety of means... but what I am wondering about is questions like, is an Application a "subtype of" Service? Or is a Service "composed of" Applications? What is the relationship between an SOA service in a UDDI registry, and an ITSM service in a Service Portfolio? Between a service in the service catalog and the service portfolio?

These are tough questions, and there is no way to make everyone happy, short of declaring a universal, weak CI type with arbitrary recursive relationships on it, the ITIL v2 approach which I have critiqued here and here. (I have attempted an IT domain model here and in my book; other notable attempts include Dave Hay and some of the work in Marco/Jennings.)

Does CDMBf intend to assist in the evolution of an IT domain language with CMDBf? What you've done so far may be necessary, but hardly sufficient...

Charles T. Betz

CMDBF will boost Zenoss

Marv, by linking the operational/config distinction to VMs you've turned a few lights on for me , thanks.

I'd be interested in your views on my statement that CMDBF will give a boost to open source competitors such as Zenoss

Can Open Source Software compete in the CMDB Space

Its foothold is undeniable, its just that you have to look under the covers to find it. Most of the major proprietory products that operate in enterprise have all of these nice little bits of open source code binding the whole thing together. Linux and Unix just go hand in hand. As for the Zenoss getting boost from the proposed architectural principals of the CMDBf, well I hope so. Its an excellent product, but any organisation wanting a CMDB will be left short on their expectations overall. It does do several of the most difficult areas. I personally have been using an alternative to Zenoss. It does a great job of the relationship mapping. ie: Host>Host Group>Host Parent>Service>Service Group>Service Group Parent. and these will be areas where many products will fall short. So in that respect it will do very well. If you have nothing implemented Zenoss will get you 60% of the way there towards a CMDBf structured system. I've got many of the shortfalls covered with other features for a CMDB. Essentially thats why I setup so I could provide this community with some guidance as to what is available under open source. The CMDB can well and truly be covered under open source integrations of product suites. There are downloads hosted from the site in vmimage formats, so you can run them up quickly. Thats probably where open source will win out in the end, by distributing under no cost GPL licensing


It is also cool to hold all your CAB meetings in a Lear jet

if the ideal CMDB is in the mountains of Zanskar (one of my favourite places), I'm happy to start walking there from here. I agree it will benefit me to do so (I can use the exercise). But it would not benefit me to attempt to get all the way to Zanskar: a few miles up the road here in my home village will do.

A few companies need to make the full ten thousand mile journey. Most of us are in need of a good stroll. The ITIL industry insists we all need to meet up on the mountain tops in Zanskar.

There are far simpler solutions for most organisations than a full by-the-book CMDB. CMDB is a techoes dream. As I said in "Top 10 reasons NOT to do CMDB":

It really is cool to be able to ...CMDB ... It is also cool to hold all your CAB meetings in a Lear jet.

Syndicate content