Search BMC.com
Search

Share: |


-by Van Wiles, Lead Integration Engineer

 

I see a lot of questions about modeling and querying relationships. The last one I saw was on BMC Developer Network, related to a poll Anand Ahire raised (Re: List Top CMDB searches) about common queries in CMDB. The basic question is how to find every CI related to an employee when they leave a company. This might be a graph query like Organization -member-> Person -related to-> CI (forget arrow direction for now since that is another big topic).

 

Classifying the Person relationships is more subtle than you might think. A person (from which employee is derived) may have a relationship to many configuration items. Some of these CIs are computer systems in the possession of the employee that need to be returned. Other application system CIs may have been administered by the employee and need a new administrator. Maybe the person is a member of a "role" which administers a group of CIs. Maybe the person was located in a room and there are computer system CIs in the same room, but there is no instance in CMDB to represent the relationship between the person and the computer systems. Or, an analyst may have determined the dependency of the person on the computer systems and created additional instances of "dependency" or "impact" relationship classes in CMDB.

 

This flexibility in modeling makes impact models easier to create, but harder to consume. BMC can help by proposing modeling practices, but of course that will limit flexibility so there are tradeoffs to be considered.

 

Standards like CIM help a little, by providing defined associations between managed elements of certain classes. But CIM is really designed to represent and manage operational elements in a CIM Object Manager (i.e. an in-memory model). The concept of an ITIL CMDB is not a perfect fit for CIM. For example, storing and managing all the CIM association classes as CMDB relationships is simply not scalable in most cases.

 

The CIM "meta-model" could be used to represent relationships as instances of association classes. But what if a relationship has both component and dependency characteristics? CIM requires at least two instances of the association classes (subclasses of CIM_Component and CIM_Dependency) to represent these two aspects of the same relationship. Extrapolate on this and consider the multitude of possibilities and you start to see the management problem that can result from a pure CIM approach to CMDB.

 

So I have two basic issues with using CIM_Dependency as a base class for CMDB dependency relationships. First, about half of CIM association classes are derived from CIM_Dependency, but I think in most cases dependency is only one characteristic of the relationship, not the fundamental type of the relationship itself. The fact that there is a dependency arises from the fact that one element is connected to, hosted by, a functional part of, used by, legally bound to (, etc.) another element.

 

For example, my child is dependent on me, but this is not a dependency relationship; it is a family relationship. The dependency will end soon, but the family relationship will not end. Actually I now depend on him in some situations (like moving furniture for example).

 

That brings me to my second issue. The direction and level of impact in a dependency relationship can vary depending on the situation. Modeling the parent-child relationship as dependency might require me to create a "financial dependency" where the child is dependent, and a "labor dependency" where parent is the dependent. A really smart analyst or analysis program should be able to determine, based on our actual family relationship and respective financial and physical attributes, what dependencies exist for a given situation.

 

Ideally, the roles in a CMDB relationship record should say nothing about the roles of the endpoints. This should be described (as much as possible) by metadata about the relationship type, and by analysis of the situation in which the relationship is being evaluated.

 

All this is just to illustrate a fundamental principle of modeling in CMDB - minimize the number of records that must be maintained about an IT configuration, and try to capture the static, actual nature of the configuration rather than the situational or real-time aspects. More "brains" should be invested in the analysis of the model, and more "brawn" used to capture reliable configuration information.

 

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

Filter Blog

By date:
By tag:
It's amazing what I.T. was meant to be.