One rule of thumb that I like to use is:
What does your business report on? What is important to the business? To use Dougs example below, a smart telephone could be mapped to ~5-10 CIs. But would you report or manage all of this information? Probably not. You might just be interested in licensing and when is a smartphone obsolete. Then again, you might be interested in OS upgrades, or does the phone have a headset, or what is the replacement value, or what is the discounted value if technology exceeds cost. Or you might just want to have a count of who has phones? This is kind of a funny because Doug doesn't have a smartphone. :) The bottom line is that the CMDB has given you a blank slate and you need to do the analysis to decide what makes sense for your company. Analysis sometimes takes 4-5 passes. If you have legacy data, use it to do the first pass. Legacy data will show trends and how you are currently reporting or managing. Continued Improvement is the key goal. Hope this helps, Gordon ----- Original Message ----- From: "Doug Mueller" <doug_muel...@bmc.com> To: arslist@ARSLIST.ORG Sent: Wednesday, November 7, 2012 3:07:12 PM Subject: Re: CI's ** Lisa, You can map things to wherever you want. The spreadsheet you are referencing is just a set of guidelines that we have found being best practice. The key would be the thing to the class with a recommendation on type. Product Categories are much less critical and vary much more widely. Change those as makes sense for your org (but be consistent within your org). Now, on the phone example… A telephone (old, hard-wired device) and a cell phone are RADICALLY different devices. The cell phone is a full fledged computing device that can have internet access, computing capability, storage, and many more things. It is a network addressable device. A telephone is none of those things. It is just a box. Now, if you have telephones that have computing capability, they really should be ComputerSystems too and not just equipment. The key here is the very different capabilities and needs for and uses of the device. Yes, it is a pain that these are different classes. Where are you headed – toward smart devices as telephones or toward dumb boxes? Maybe you should consider modeling them all as ComputerSystems (even the dumb ones) if the direction is smart phones just so that all phones are in the same class? Something that is reasonable to consider. But, I would resist having cell phones as just equipment unless you are completely ignoring their computing capability and treating them as just dumb phones for the purposes they are in your CMDB. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Lisa Kemes Sent: Wednesday, November 07, 2012 12:00 PM To: arslist@ARSLIST.ORG Subject: CI's ** Thank you very much for the explanation. I think I'm getting there. Sometimes when it comes to mapping I feel like this: http://www.youtube.com/watch?v=VW27kyh7PVM (sorry for the early Friday Humor) You've answered my main question (do I HAVE to force my CI's to use only the Product Categories in the spreadsheet?) but, I will use the existing Classes. Should I try to follow the spreadsheet suggestions as much as I can (when it comes to CI's and Classes)? For example, on the spreadsheet the Telephone CI is under the Equipment class, but the Cell Phone CI is under the Computer System class. These are just suggestions correct? If I wanted to put cell phones under the Equipment class, that wouldn't hurt anything would it? Lisa ----------------------------------------------------------------------- Lisa, Welcome to the wonderful world of mapping…. I have an x, where do I put it, what do I call it, how do I identify it, how do I name it, how do I ????? It is not a simple task. You seem to have the document that is available with some suggestions of where to map things. It cannot include everything and to some degree, there is a decision you need to make about what you want to do and how you want your data represented. Let's take a look at the different decisions you need to make. Note, that they are a series of decisions that build on each other but that are relatively independent of each other at the same time. First, what CMDB class should be used. This is the first decision whenever you have a new thing. I have an X and what class should I use (or do I need a custom class)? Generally, you should find a class that exists and is appropriate for the object. Only create a custom class if you really have something that doesn't fit. So, let's take this example, what class does it go into? Well, it is pretty clearly something that is a piece of equipment and so can go into the BMC_Equipment class. Second, but if everything like this is equipment? How do I tell it apart for what type of a thing it is within the class? That is where the Type attribute comes in. This is an attribute on BMC_BaseElement so every class contains this field. This field is a character field that you use to differentiate within a class between different subtypes of things that are within the class. For example, for the BMC_ComputerSystem class, you may have a type of Hub or Router or Laptop or Server or …. to tell different types of computer systems apart. NOTE: You can have different pictures show up on Atrium Explorer for the same class by having different pictures for each type within the class. So, you can differentiate graphically on the picture even within a class. So, let's take this example, we have it in BMC_Equipment, now it is time to set the Type field to something. This is where you now need to understand if you care about the distinction between a digital camera or an analog camera between a camcorder or a video recorder or a ….. You make the choice of how many type categories you want to have based on what type of data you are going to be entering and you list the types that are interesting to you and then assign a value for the object to the appropriate type within the set of types you are going to allow. In your case, call it a Video Recorder if that is what you want the type to be. NOTICE that the CI class is BMC_Equipment (not Camera and not Video Recorder), then the TYPE attribute tells what type of equipment it is. Now, we come to the Product Categorization attributes. These are really not dependent (although they are tied) to the Class and Type. These attributes should be used to record specific categorization and Manufacturer and models of the object. So, in your case, yes, the Manufacturer may be Panasonic and the Model/Version number would be whatever it is. A manufacturer/Model/Version is generally tied to a class and type in the foundation data definition so that you can tell if you find a Panasonic Model Q35R, it means it is a video recorder that goes into the BMC_Equipment class with a type of Video Recorder. There is never going to be able to be a complete and definitive list of everything that you may want to model. But, if you follow the guidelines given in this note, you should be able to find a clear and reasonable location for the objects you are putting into your CMDB. For example, we have a customer modeling airport gates. This is never something that would have been thought about from an IT modeling perspective. But, it has been modeled in the CMDB. It turns out they used the BMC_Equipment class with a Type of Airplane Gate. I hope this has helped and has not added further confusion. Doug Mueller _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
