CSDM relationship model: CI relationship vs reference attribute

[jonathanwaldo]

In the CSDM 2.0 whitepaper, guidance suggests that some relationships are represented as CI relationships and others as reference attributes. What's the reasoning behind not using one or the other for all relationships?

[DaveHertel · Accepted solution]

Hi -- relationships are useful in IT ops tools such as Event Mgmt, etc to depict dependencies.  An Application Service that has relationship to lower level entities could be revealed on event mgmt dashboard.   For example, the App Service leverages the relationships of things like application instances & server CI instances. The EM dashboard can show degradation of service when relations are used.  An App service that may have been built by Service Mapping, to convey its supporting infrastructure like servers, applications.  ( the lines depicted lower right portion of snippet below)

Meanwhile, reporting may be easier when the REFERENCES are leveraged to show X item has a reference to Y, Z entities.  Relationships are generally more challenging to report upon... because so many database tables might have to be referenced CI>relationship-table>CI ... and on an on.. depending on use case.

I'm sure others have better examples -- but this is but 1 example where References vs. Relationships have value.

Hope this helps?

[SteveMac1]

In one, I actually implemented both for the same relationship, exactly because of the points Dave said. 

In our case we have a batch job that implements a certain batch component. With that in mind, it made sense to set it as a referenced attribute on the job. At the same time, we wanted to be able to show the relationships of these components to other components, showing the complete hierarchy. To cover that, we set up the suggested relationships. While most of the CIs are created through import sets, to make sure the relationships stayed up to date if they needed to change the reference attribute, I put Business Rules in to add / update / delete the relationships. 

With this we get simple reporting (what jobs implement component X) as well as a pretty picture for the user who needs to see the complete hierarchy. 

One of our next projects is to implement this for all of our integration endpoints so development teams can follow the complete process flow as they send / receive data. 

[Pete Laws]

Where the suggested relationships you used just so you could show in the dependency view how they were related? Essentially that's what I would like to do, I will still reference the fields but i want to show the hierarchy in the dependency view. 

My hope is that this does not effect any other reporting downstream, have you noticed if your reports were effected at all?

[SteveMac1]

Pete,

For the moment, yes the dependencies were set up for the dependency view, but in the future expect to use that data around correlating alerts and having insight into Affected CIs for a change. 

I have not noticed any issues with reporting. Our standard reports are being built around the reference fields, but as we get more mature expect that some CMDB Query Builder queries will be built around the relationships. 

Steve