Are you asking how FootPrints defines them or how does ITIL?
The relationships in the CMDB are uniquely defined by you or your administrator under the CMDB|Administration|Relationships screen. Therefore, definitions can vary widely.
There are many places on-line that lists out relationships but none that really define them. If you need some help planning the relationships, check out this old but relevant document from BMC. Start on page 101.
ITIL doesn't really define them...neither does Footprints. FootPrints contain some of the ones on the above list but it doesn't define what they mean. So I may end up using "installed on" when I should use "runs on" or use "connected to" when I should use "depends on". These classifications of relationship types must mean something. Lotsa people are using them. If they are in these tools so that we...meaning each individual person can define them in whatever way they choose to do so whenever they choose to do so...that doesn't really sound like a "standard" to me. Although I understand I could be way off base on this.
But if there are standard definitions for these i'd like to know what they are and where they can be found. If not maybe we can write some on this forum...maybe even in this thread.
I have that book in both electronic and in printed form. Page 103 gives an in-depth view of "depends on" but doesn't really define what it means. One can derive a definition from the analysis on 103 but that definition will vary from person to person as many definitions do. What is called "the dictionary" has definitions of what words mean even though people use words in many different ways that are not outlined in "the dictionary". But "the dictionary" is the "standard" for word usage.
I was hoping there would be something similar for word or phrase usage when it comes to a "standard" for CI relationship types and their meanings.
OK...found this document on the Internet:
It has a really good list of CI Relationships Types and also has a pretty comprehensive list of Attributes Types as well. It doesn't really have definitions but it does have descriptions of what they mean. Really good start.
There is no right or wrong with ITIL as it's a framework that you can fill in so it works for you. You are asking for how other people would use the relationships that you found, but you should be asking the question what will work for you.
Pick the relationships that according to you make sense and add your own definition on what they mean and make sure you note those definitions down, so there will be no confusion on what they mean for your organisation. When you need a new relationship to cover something you hadn't throught off before you can add to your own documentation to fill out the missing piece.
You give the examples of "installed on" and "runs on" to me those will mean the same thing, so I would use one or the other, however you might have a good reason to make a split somewhere and use "installed on" for something and "runs on" for something completely different. As long as you make sure that everybody in your organisation uses it in the same way (generally because you documented it and made sure everybody understand that it means one thing) then that's "right" for your organisation.
While I'm not an ITIL expert I'd suggest picking just those relationships that work for you and leaving out the rest of them as you'd be bogging yourself down by using things that either don't apply or don't make sense as you start to think of things to use them for rather then picking relationships that you actually need.
Thank you. If we are properly planning our CMDBs in terms of writing requirements, design, critical design, etc. documentation we should be attempting to be aware of all of the options in order to choose what options will work best for us.
There are a lotta people who keep saying use what works best for you. How will someone know what will work best for them unless they are away of as many of the options as there are available?
Michael mentioned the Step-by-Step Guide to Building a CMDB that was put out by BMC. Everyone should take a look at that process. Who does all that? No one I know...but it provides you with as many of the options as there are available for a guide to building a CMDB..a framework so to speak. I have read where you should not even approach building a CMDB as if it were a project. But this book points out why it is important to do so.
What I was essentially asking for is options not only because I was exploring them at the time of planning but because I think we all need them and can benefit from them even if we don't use all of them.
Why I suggest that you use what you need is for a good reason. If you didn't think of it yourself, then it's bound to be less important then the things that you did think about.
In constructing a CMDB I'd suggest starting small and then slowly building it up rather then writing out an entire plan, only to find out that it takes longer to keep it updated then it takes for the data to become inaccurate.
I think you're missing the point. I understand to use only what I need...I see your point. I see your point in starting small and building up from there. We are on a public forum. I'm not only asking for me I'm asking for a lotta other people who may search the topic at a later date.
My point is there is no way for many other people to know what they need unless they have a decent understanding of what the options are. Many people may not follow that logic. You seem not to...but that's okay. I understand your point and many other people may understand it too. But for those who do not understand your point you may want to reiterate it yet again. Not trying to be mean but really?
All the relationships for the CMDB can be configured exactly as you wish. You can delete all of the example relationships and add new ones that will meet your needs. The important thing is that you define how you are going to manage your CMDB and then define relationships that correspond to your model.
In our organization, there are many changes to the CIs in the CMDB and it would be unrealistic to think that anyone could keep up with manually tracking all such changes. For this reason, we have built an integration between our enterprise monitoring system (Zenoss) and the Footprints CMDB. When devices are found and brought into monitoring, the changes are written to a MySQL database. Based on automated configuration rules within our monitoring system, new CIs are automatically classified within certain service groups. This grouping then specifies the relationship of the new CIs to existing CIs. To keep this all simple enough to keep it automated, we only use a single relationship type of "depends on". It simply means that the given CI has service dependency relationships to other CIs. We run scheduled imports of various CMDB rulesets, including relationships, that update from the MySQL database via an ODBC connection.
If we had a simpler and more static architecture, we might choose to use more relationship identifiers to help more carefully define a CI in our environment. The tradeoff is that the simplicity of the current model allows us to have an automated process that is pretty accurate in showing groups of interdependent CIs. If we did not use this model, our CMDB would become very outdated in a hurry.