CMDBf Specification Implementation Options

Here are a few ways the CMDBf 1.0 spec (not a standard yet) can be implemented.

First - it is important to understand that the spec describes web services.  These services can be written and delivered by anyone, not just the vendor of a particular CMDB or MDR.  So let's say there are three scenarios (there may be more):

1. Each CMDB and MDR vendor produces its own CMDBf services for its own product lines
2. Third-party software vendors produce CMDBf services for popular CMDB and MDR products and market these adapters independently
3. Consulting service providers produce CMDBf services for custom applications to be used with other CMDBf implementations

I will guess that these are all viable options and could very well come to market in the reverse order from above (custom implementations first).

Second, the spec can be implemented in many ways - "push-mode", "pull-mode" or both, varying levels of query support, varying record types, etc.

Now comes a tricky question - can you market these adapters without a common data model, or an exponentially-expanding set of data-mapping objects?  The point here is that some maturity will be required before this is really plug-and-play.

So, leaving the modeling/mapping question aside for now, let's see how a third-party could produce adapters for a pair of MDR's.  I'll start with a picture.

In the picture above, all the CMDBf services and processes are provided by a third-party (call it Lavender Software.) Lavender has adapters for each MDR proprietary interface, plus transformers to register items and relationships from Vendor A to Vendor B CMDB, and a User Interface to query the registered CMDBf Query Services.

This picture could change if one or both vendors produce their own CMDBf services and the customer wants to switch.  In this case, Lavender Software might provide a way to switch services to another vendor.  In this case, you can imagine that it would be much less painful to exchange information between CMDBf services in a common format, at least in the case of registration.  Additionally, it would be really helpful to the query UI if items of like-kind had common type-names (like Incident or Computer System for example).

In the final picture, vendors A and B have provided XML schemas and registration processes for their services, and a contract integrator has been hired to connect the services.  All that is required is for the contractor to use the registered services and provide a query client interface for the customer.

Final note: open standards and open source go together like shoes and socks (except that standards smell better with age.)  There is an open source project giving some very interesting insight on a CMDBf implementation over SML/CML starting here: http://wiki.eclipse.org/Leveraging_CMDBf.  This is part of the Eclipse COSMOS project which is sponsored by some of the original consortium companies.  It should be a useful starting point if you are interested in implementing CMDBf.