Configuration Item relationship directions

Colin13 · ‎01-07-2021

Currently working on the CMDB and CSDM and questions are being raised about relationship directions, using a piece of a equipment in a rack, which direction should the relationship go, should it be that the rack is the parent of the equipment,

e.g

an application service would then be a child of the IP router if that was the last object

I have seen examples using both directions and hoping that people can offer their comments and experience on this as I can't seem to find a definitive answer

thanks

Colin

Barry Kant · ‎01-07-2021

Hi Colin,

I think there are 2 ways to look at this, and that can be seen in CSDM as well.

From a Business side it is modelled from an impact point of view, meaning the impact upstream the relations. As CI 'I am supporting this Application Service --> upstream'

From the Technical side it is modelled from a supportability point of view. As Technical Service Offering 'I am managing/supporting this CI --> downstream'

The datacenters are to be compared with the Technical side I would say, as it is not seen as Business.

About CI Relation types: I would use an exclusive relationship type, and limit that one from the impact analyses logic (which is not ootb).

Example in the visualization:

if an Incident is raised on this router the impact analyses show that the Rack and the Computer Room are impacted. Where impact wise it would be the other way around. I there is a power outage in the rack the router will be impact.

In my opinion it is a different purpose where impact analyses might not be needed.

Cheers,

Barry

View solution in original post

Colin13 · ‎01-08-2021

that makes a whole lot more sense now, so there isn't a definitive direction?

It all depends on how you use it, so the CMDB will in some places have relationships in both directions?

Thanks again

Colin

mbourla · ‎01-08-2021

My own view has always been that the parent in a CI relationship depends on the child in some way, regardless of that actual relationship type.

If there is some issue with the child, then the parent is potentially impacted. In this example, if you lost the room (in a fire, say) then you'd lose racks. Losing a rack would impact all the devices housed in that rack. And then would impact all the upstream devices, items and ultimately services that depend on that rack.

So I would definitely have those 3 CIs related in the reverse order of IP Router -- in rack --> Rack -- located in --> Computer Room.

And in fact, looking at the relationship names, where the bit before the "::" is how the parent relates to the child, that seems to be consistent with the relationship names.

Regards

Michael

Colin13 · ‎03-18-2021

Thanks all,

I've been working with this more and have worked out more details on it

As you say Michael, it very much depends,

In our case we can have a core router (IP router) that will need to have a Hosted on::Hosts relationship to the network adapter, but the client router (IP router) will need to have a Owns::Owned by relationship to the network adapter to ensure that if the core router failed the impacted services actions flow the dependancy mappings upstream and highlight the impacted Client router

I hope this helps other people and stops them having a CMDB related mid life crisis like I did

Cheers

Colin