- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hey, this topic bugging me a lot as my architects have asked me to have a parent-child relationship amongst the information objects same as like we do for Business capabilities. But as you understand If i go with them then have to create manual relationship using relationship editor for ex. contains::contained by between the objects.
My only concern is that they are reluctant to use Data classification tags and Data domain in grouping as L1 and L2 rather they wanna stick to parent-child relationship between objects that should go into table cmdb_rel_ci.
I am concerned with this customisation/configuration what could be the operational impact in the near future with this new relationship.
Do we call this as a customisation or configuration ?
can I please get your input if this is the best practice if I create hierarchy and doesn't impacts me down the line.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hi,
I have technical opinion here. The cmdb_rel_ci has been designed to represent operational relationship between Configuration Items with primary purpose of information dependency mapping, service topoloy or discovery sourced relationship.
Representing data clasifiaction and hirarchy of Information Object may surface during CMDB dependency visualisation or service graph traversal. It would be challenging to exclude them everytime.
Yogesh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
6 hours ago
Hi @averma1
Information Objects are not hierarchical, other than belonging to a Data Domain. I don't understand the requirement to model with CI Relationships. Business Capabilities are a completely different concept that describe what a business does from very high level to very specific. Information Objects just express the nature of data stored on a database so by their very nature are single-level. It's also the OOTB architecture. I'm sure your organisation has a governance approach for customisation - this is an example of something where the benefits are outweighed by the technical debt.
I would resist this request with the same justification that the CSDM whitepaper has for not creating hierarchical business services - it obfuscates what's really there in your business.
I hope this helps!
Mat
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hi,
I have technical opinion here. The cmdb_rel_ci has been designed to represent operational relationship between Configuration Items with primary purpose of information dependency mapping, service topoloy or discovery sourced relationship.
Representing data clasifiaction and hirarchy of Information Object may surface during CMDB dependency visualisation or service graph traversal. It would be challenging to exclude them everytime.
Yogesh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
6 hours ago
Thank you @yogesh41
If I keep manullay created relationship in rel_ci table considering it non operational using it only for Business Architecture , will this create any hinderance in near future?
Can you please give me some more insights on CMDB dependency visualisation or service graph traversal
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
6 hours ago
Hi @averma1
Information Objects are not hierarchical, other than belonging to a Data Domain. I don't understand the requirement to model with CI Relationships. Business Capabilities are a completely different concept that describe what a business does from very high level to very specific. Information Objects just express the nature of data stored on a database so by their very nature are single-level. It's also the OOTB architecture. I'm sure your organisation has a governance approach for customisation - this is an example of something where the benefits are outweighed by the technical debt.
I would resist this request with the same justification that the CSDM whitepaper has for not creating hierarchical business services - it obfuscates what's really there in your business.
I hope this helps!
Mat

