Service Desk Practitioners Forum
cancel
Showing results for 
Search instead for 
Did you mean: 

Configuration Item Relation Types

SOLVED
Go to solution
Highlighted
Holland Peterso
Occasional Contributor

Configuration Item Relation Types

What is the best way to use the CI relationship types? What do the different types mean and what is the effect if you define one relationship type over another.

I have read on the forum that Parent-Child is a dependency relationship where the child can not function with out the parent being available. However when would you use the relationship type dependent vs parent-child?

And do these different relationship types affect your SLs and availability reports?

If someone can take the time to give scenarios or examples for each of the following relationship types I would be much obliged.

Parent-Child
Connected
Installed software
Document backup
Original
Dependent
Contains
Is part of

Thanks!
Holland
13 REPLIES
George M. Meneg
Honored Contributor
Solution

Re: Configuration Item Relation Types

Hello Holland,

Consider the following Configuration Items

Desktop PC, hard disc, speakers, sound card, monitor, antivirus software and external usb kit (drive & cable)

Hard disc and sound card are childs of Desktop PC. Monitor is connected with Desktop PC while speakers are dependent on sound card and also connected to PC. Antivirus is installed software. Usb kit is connected to pc, while drive & cable are parts of it.
menes fhtagn
Dan Ioan
Frequent Visitor

Re: Configuration Item Relation Types

Hi Holland,

A good example from George. Is not easy to choose the best relation type between CIs. To do this you should have in mind two basic criteria:
1. Physical or logical connection between CIs.
2. OVSD features regarding parent/child and free form relations.
To give you an example, a good choice is to create parent child/relations between HW and SW CIs. (SW CIs are children). The reason is application ability to control the number of parent/child relations until Max. installation value has been reached.
Other examples:
1. A printer is 'connected to' a PC
2. A license 'grants' a SW CI ('granted by')
3. A procedure document 'reference to' an application ('referenced by')
Hope this helps you a little.

Best regards,

Dan
Mark O'Loughlin
Honored Contributor

Re: Configuration Item Relation Types

Hi Holland,

Say you have a pc and a monitor. If the pc fails the monitor can't display anything and vice versa. This dependancy is expressed as a parent-child relationship as the parent (pc) is affected by the child (monitor). Basically one CI cannot function without the other.

Peer to Peer relationships will establish a relationship between CI's without this hierarchy of parent child. A pc will work if the connected printer is not working and vice versa.

It is important to:
Keep things simple
Have as few relationships as possible
Establish reverse relationships
Holland Peterso
Occasional Contributor

Re: Configuration Item Relation Types

Thanks for all the great replies. I understand the examples however here's a specific example question.
If I have a switch connected to a several servers, is the relationship connected or dependent? The servers can't 'talk' to any other device unless the switch is up but is it really dependent?

Also, does the different relationship type have any impact on my SLA for the service or is the relationship type really for further clarity in the 'service mapping'.

Thanks,
Holland
George M. Meneg
Honored Contributor

Re: Configuration Item Relation Types

Hello Holland,

It depends on the view point, I'm afraid. If you are using relations to map "network functionality", then yes, servers are depended on switches/hubs/routers/modems/whatever in order to have network connectivity. But in this case, the server is not only dependend on switch, is also depended on its network cards, cables etc.

On the "physical" level a pc is connected to a network device.

As I said, it depends on the viewpoint.
menes fhtagn
Mark O'Loughlin
Honored Contributor

Re: Configuration Item Relation Types

Hi Holland,

As George stated its a view point.

I would say that they are connected. The server does not need the switch to work. The server can boot up and you can manage the OS and apps regardless fo if the switch is connected or working etc.

I do take the point that for connectivity and for the server to "server" requests it needs to be conected to other communication devices (switched, routers etc.) but I take the approach that these devices are "connected".

If say the switch failed, the server does not fail also it is still operational. It however cannot server requests.
Holland Peterso
Occasional Contributor

Re: Configuration Item Relation Types

Ok - one more question.
When should I use dependent vs. parent-child?
Mark O'Loughlin
Honored Contributor

Re: Configuration Item Relation Types

Hi Holland,

as mentioned earlier in the thread the approach I take is that the dependancy is expressed as a parent-child relationship.

Therefore I don't use "dependancy" as a relationship but relate the CIs and Parent / Child relationships
George M. Meneg
Honored Contributor

Re: Configuration Item Relation Types

Hello Holland.

Again, it depends on the view point. In the general consensus you use parent-child relations to display the physical build-up of a list of CIS while you use "dependent" to describe the functionality.
menes fhtagn
4Adam12
Collector

Re: Configuration Item Relation Types


I think what would be useful (to me anyway)would be to talk about the types of viewpoints that should be considered, and from there create relationship types that are specific to that view.
From a HARDWARE perspective a NIC card is a child (or subcomponent) of a server and the server is connected to the switch. The server as a whole does not function correctly with a failed NIC (sure it will boot and run OS but it is a boat anchore)and so they are dependent while the switch and server are not dependent on one another. Hardware type relationsships are the easy wins and a good place to cut teeth when starting.

From a SERVICE perspective:
You can define a relationship type called upstream/downstream that is in effect the same as a parent child relationship but is defining a SERVICE perspective relationship. I'm kind of brainstorming here but I guess you would have to map how the service "flows" to the customer. A service is provided using a piece of software, software resides on (needs) a server, server connected to (needs) a switch. It is not quite that simple because each of those steps have their own dependancies for example the software may need a DB to function and there are server and network dependancies there, and the server has it's hardware perspective dependancies. But if all goes to plan through this part you have a service that is available to the network on a corprate level at the network core. Distribute that service to specific locations away from the core via some more network service and hardware dependancies. From there to an individual user through a connected PC.

A harware relationship of "connected" Will be an indication of a service "upstream" or "downstream" relationship.

Redundancy adds a level of complication I think. We are no longer dependant on a single data path or NIC card but on one or the other being available. Logicaly it is simple xor operation but how is that represented in a CMDB relationship? Service path "A" and "B" where as long a either/or is available the SLA is being met? Mapping out these seperate paths also leads to identifying single points of failure.

From a service perspective should the application providing the service be the root of service dependancies (each service has it's own root) or is the network condidered the root for all services? Services flow upstream to the network and from there back down to the user?


Thanks,
4Adam12 over and out.
Robert S. Falko
Honored Contributor

Re: Configuration Item Relation Types

Ahoy Holland,

We use two simple rules to determine the type of relationship between two CIs:

1) We use parent-child ONLY if we want to benefit from OVSD's built-in functionality, which limits the number of such relationships to the total number of the non-unique child CI.

2) For all other relationships, we create as a relationship name a short phrase which, when read by the user, makes it completely clear what the relationship is. For example:
is installed on
is connected to

and so forth.

Since there is absolutely no built-in functionality to a relation type (other than parent-child), easy comprehension is the only criterion we use.

-Josh
4Adam12
Collector

Re: Configuration Item Relation Types

So essentially from a service perspective OVSD has no functionality in the CFIA arena. Unless you use parent / child relationships from a service perspective rather than hardware.
Is that accurate?
Robert S. Falko
Honored Contributor

Re: Configuration Item Relation Types

There is no built-in functionality.

-Josh
//Add this to "OnDomLoad" event