I agree with your comment on getting the relationships right, and it's true that many of the classes can be used pretty much any way you like. However, I keep going back to the idea that each class was created for a particular reason with more or less specific uses in mind. I prefer to try to keep their actual usage pretty much in line with their intended usage.
I think Communication Endpoint would more aptly apply to something like a port on a switch or a router rather than the device itself. If you take a simple example of a small switch with 8 ports, you would put the switch in the Computer System class, and then if you wanted to track what was connected to each port (which is often important information), you could model each port with a Communication Endpoint (or perhaps a LAN Endpoint) that has a relationship with the switch CI. Each CI connected to the switch would then have a dependency relationship with the Communication Endpoint class representing the port it is connected to. Looking closer at the model, it looks like Communication Endpoint may even be more for things like actual network communication (i.e., a TCP connection on a specific TCP port or something along those lines) rather than a physical connection - then again, there are protocols at each layer of the network infrastructure... Tauf, I recall someone posting how Topology Discovery (or one of the BMC products) maps network equipment and/or communications to the list a while back. It seemed to cover pretty well how BMC does it. I'd recommend searching for that and maybe using that as a starting point, taking out anything you don't need for your scenario. For example, if you don't need to track what port on a switch a server is connected to, you could take out all the in-between CIs and simply create a dependency between the server and the switch CIs. It all really depends on what kind of information you want to track and how detailed you need to be. Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Rick Cook Sent: Thursday, June 11, 2009 3:45 PM To: arslist@ARSLIST.ORG Subject: Re: Asset Management - Creating CI for Network Equipment ** That's a good point, Lyle. But Communication_Endpoint is a pretty general classs that could cover pretty much anything that doesn't have its own class. ConnectivitySegment and several others are categorization subclasses beneath the ConnectivityCollection class. The relationships between the CIs are especially important with network segments, so just dumping them into ComputerSystem might tend to hamstring that if not done correctly. Between all of those and perhaps a few more Categorization values, you should be covered. Rick On Thu, Jun 11, 2009 at 2:27 PM, Lyle Taylor <tayl...@ldschurch.org<mailto:tayl...@ldschurch.org>> wrote: ** Which classes are you thinking of? I see ones for logical items like an IP endpoint, WAN, LAN, etc., but nothing that would account for things like routers and switches except for computer system. And the fact that they have the primary capability field that has values like Router and Switch in it would seem to indicate that that was where BMC intended to put them. Lyle From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Rick Cook Sent: Thursday, June 11, 2009 3:18 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Asset Management - Creating CI for Network Equipment ** The 2.1 data model does have sub-classes for network components. What you don't have a class for should work as a categorization subclass in one of the existing ones. Rick On Thu, Jun 11, 2009 at 1:57 PM, Lyle Taylor <tayl...@ldschurch.org<mailto:tayl...@ldschurch.org>> wrote: ** Most network equipment simply goes under Computer System. If I recall correctly, there is a Primary Capability field that you can use to indicate whether it is a switch, router, etc. if you want to. Lyle From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Chowdhury, Tauf Sent: Thursday, June 11, 2009 2:53 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Asset Management - Creating CI for Network Equipment ** What is the best method for using Asset Management to create CI's such as Network Equipment etc... ? In CMDB there are different forms for a plethora of network equipment but in Asset, under CI Type, there is a very limited set of data. Any suggestions? Tauf Chowdhury | Forest Laboratories, Inc. Analyst, Service Management Informatics-Infrastructure Office: 631.858.7765 Mobile:646.483.2779 ________________________________ This e-mail and its attachments may contain Forest Laboratories, Inc. proprietary information that is privileged, confidential or subject to copyright belonging to Forest Laboratories, Inc. This e-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this e-mail, or the employee or agent responsible for delivering this e-mail to the intended recipient, you are hereby notified that any dissemination, distribution, copying or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender immediately and permanently delete the original and any copy of this e-mail and any printout. _Platinum Sponsor: rmisoluti...@verizon.net<mailto:rmisoluti...@verizon.net> ARSlist: "Where the Answers Are"_ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. _Platinum Sponsor: rmisoluti...@verizon.net<mailto:rmisoluti...@verizon.net> ARSlist: "Where the Answers Are"_ _Platinum Sponsor: rmisoluti...@verizon.net<mailto:rmisoluti...@verizon.net> ARSlist: "Where the Answers Are"_ _Platinum Sponsor: rmisoluti...@verizon.net<mailto:rmisoluti...@verizon.net> ARSlist: "Where the Answers Are"_ _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
