Hi Kevin,
We are also rolling out ITSM 7.02 and here's some thoughts about the consolidation of everything into one class:
Certain discovery tools...when integrated through EIE are pre-configured to pump their data into the appropriate classes...so...a tool like Marimba would pump a Server into Computer System, but a Printer in the Printer class.
That's not really a problem or an advantage...just something that happens and would have to be adjusted.
Where you'll run into more issues is that the reason data is stored in different classes has a lot to do with two things. One is relationships. The other is class specfic attributes.
If you pump all the information into one class and then try to relate equipment, you will basically end up with one long list of information that you need to weed through more
carefully to identify appropriate relationships. In other words, your related software and your related printers will be a little more challenging to eyeball.
The second issue is that you'll have fields on your mega-class that only apply to a subset of data. Once again, this is neither good nor bad, but will give you records that are full of holes. For example, you might be concerned about something like a server attribute...but that would be null if you're record deals with a document.
Another advantage to breaking the data out into classes is that you can make certain fields required (and/or lock down security) when it applies to a class more cleanly than if you use a Mega Class. Once again...you can still fix that issue with workflow that checks your CTIs (T1,2,3). Here at this account, a Nuclear Server is handled differently than a Non-Nuclear Server.
At our account, we did slim it down to about 10 classes...without too much editing of class definitions.
In the end...it's all in how your customer will use the data... Remember...In the old world, we only had assets and components and we seemed to get along okay so I couldn't tell you that the Mega Class wont work. It just needs to be handled a little more generically....There is an advantage to the mega class--Reporting! No need for crazy ten-way joins!
I do have one more closing comment. We are trying to be as "Out of the Box" as possible at my account--so if you start adding a bunch of attributes to your mega class, you'll just need to keep that in mind should you upgrade.
Let me know how this rollout works for you!
[Shameless Advertising]
I'm Tim Richardson and am available to assist
with CMDB projects for those of you looking for someone who has been through it at least once--or just want to exchange war stories...
(917) 892-9510
Kevin Shaffer <[EMAIL PROTECTED]> wrote:
We are rolling out ITSM 7.x in 5 weeks and the last major hurdle we have in
our UAT is CMDB. The feedback from our users and management is the 68
classes are too confusing and they want to simplify. I recommended getting
the list to 10-15 classes, they went the extreme and said they want one
class that stores everything; services, assets, documents, etc.
Has anyone gone to this extreme of just using one class. Any advantages and
disadvantages, lessons learned, etc. I think it would be hard to identify
all the attributes to accomodate everything in one class.
The driving force behind this is Management feels users will not
relate/manage CTI's because noone will know what to classify it as ... Also
reporting would be a nightmare with data in multiple forms. Management
feels our Categorization is structured well enough to pull reports based on
it from one form (class).
TIA
Kevin
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
__20060125_______________________This posting was submitted with HTML in it___
