Share: |


-by Van Wiles, Lead Integration Engineer

 

Here are some tips on how to use records in an implementation of the CMDBf spec.

 

The concept of a record in the CMDBf spec is simple and powerful. Like ITIL version 3, the CMDBf committee separated the notion of an item from the notion of a record. (In case you didn't notice, ITIL v3 uses "configuration item" to refer to the actual thing under management, and "configuration record" to refer to a structured information record about that actual thing.)

Like many simple and powerful things, records could be used the wrong way, leaving a so-called "hole in your foot". Thus I am offering a bit of explanation.

An item can be "associated" with many records. This may be implemented as some sort of join by property on the item ID, or a set of unexposed relationships. The important thing to remember is that a query for an item may return a mixed bag of records, some of the same record format (record type), and some of different formats.

The first thing to know about records is that they could give you a clue what the item actually is. (If you hadn't noticed this, items and relationships don't have a "type".) So if your item has a "ComputerSystem" record, it's probably some sort of computer system. If it has a "ComputerSystem" record and a "Switch" record, well - I hope you get the picture. The committee chose this approach to allow maximum flexibility that supports but does not require a hierarchical or object-oriented data model.

The specification does not differentiate between an "is-a" association and a "has-a" association. For example, if an item has a "ComputerSystem" record and a "SupportContract" record, is the item a computer system or a contract? That could be the first "hole in your foot". There are two ways to deal with this. You could decide that in your world a support contract could be associated with any item and will never be a separately managed item. Thus you may structure your items as I just described.

The problem comes up when this type of MDR is federated with another MDR that manages support contracts as separate items. In that federation, a query for contracts may yield more items than the client expects. The other way to deal with this is to create a separate item with a "SupportContract" record and create a relationship with a "SupportedBy" record, where the relationship source is the item with the "ComputerSystem" record and the target is the item with the "SupportContract" record.

This is a better way to model this, because in the most likely scenario, one MDR may have all the support contracts and know very little about the supported configuration items.

Think carefully about whether a record represents something that could be managed, or whether it is simply a collection of properties that could be associated with any item or relationship.

I guess I'll post more entries on this subject since there are several other tips to be considered.

 

The postings on this blog are my own and don't necessarily represent BMC's opinion or position.