Susana Where SD can get too large is that you can set up auditing on each of these fields, and thus there is a lot of overhead in setting these up. Then there's your CI History file which can get very large with what is changing in all these CI attributes or fields.
Gyula, It sounds like Susana maybe trying to set up what we have set up in the CI database, and that is a checklist for the set up of Servers or basically using fields on the CI form to identify what is set up on Servers, and who is modifying these fields. It's an excellent spreadsheet function but should it stay as a spreadsheet (which seem to proliferate too much and then become more up to date and used more than SD), or should these 'checklist' items be a part of the CI form?
I think the answer to your question depends on how your Service Management processes are able to use the information in the CMDB, and the nature of your organization, rather than technical issues.
If you are the US Army, then it is probably far too small. If you are the corner grocery store, then it might be excessive.
As for the support of your processes, here are some examples:
Can the Service Desk quickly and reliably find the CI(s) that are related to a service call, or do they waste a lot of time and end up selecting no CI or the wrong CI?
When you change a CI, are you able to reliably identify which CIs are impacted by that change and which CIs need to be updated?
Are the responsibilities defined for each CI? Do they all have someone (or something) to keep them reliably up to date?
If you can answer Yes to all these questions, then the CMDB is probably not too big. However, if this is not the case, then you might consider making some changes. I believe that the only thing worse than a CMDB with a lot of CIs in it, is a CMDB with a lot of CIs that are not up to date.
In my opinion it is not the size of the CMDB but its complexity relative to the available effort to keep it up to date that is important. This is because a CMDB that is not accurate will no use what so ever.
The approach we take in general for our customers is that anything (attribute or relationship) in the HPSD CMDB must be put under Chnage Mgt and so you do not put in attributes where the owner of the data is not prepared to have to set up a Chnage record in order to ensure the attribute is amended. This does not mean that this information is not held at all, just not in the HPSD CMDB. This approach works well with discovery tools as you can set up a smart action to launch the tool to see the attributes not in the CMDB.
If you will have 1.000.000 CIs in CMDB, then they must be really well organized and separated by category etc. For example, it can be a hard challenge to select a CI using quickview button. You may wait 10-20 minutes to select a CI when you are registering a service call etc.
About 400 attributes, you have to ask yourself that if they are really needed. I saw in the past that service desk application used for goals which are definately not what sd is designed for (IT service management), so attributes become quite a number. Instead of just adding a new custom field for all cases, a question should be asked if one of the currently defined fields can be used to achieve the goal.
I have encountered several projects where indeed the amount of CI's were quite large. With the use of the limitation on searches this is really good manageable. But indeed 400 attributes seems enormous to me. I usually ask what the use of each attribute is. If they are not used for incident resolution or important information for other processes I usually kick them out. Customers tend to overload the CMDB with non important information or think that the CMDB is in fact the inventory of the company
best advice with a CMDB isat the beginning to keep it simple. Set up the process and forms and agree to house only the must have attributes (basically the ones you can't live without) but keep the number low. It is far easier to grow the CMDB attribute list once everythig is established and working rather than having a large number of attrubutes that are not up to date or populated etc. Also as said earier have the CI's under change control.
I have spent 6 months reworking a CMDB due to the fact that they started off too big so all the attributes were never updated or under any type of control. We had to strip the CMDB back to the bare basics and data gather all the data from scratch as it had all become obselete.
Hope this helps - Any points for all the helpfull replies?
Another thing philosophically speaking... We believe the real power of a CMDB integrated with the Service Desk is to gain relationship info between CIs rather than attributes from other automated management databases?
If there are other feeder databases with huge amounts of attributes for the CIs then maybe giving people quick access via a smart action from the main CI into the other system (HPSIM, Node Manager, SMS???) is more logical than pushing all attributes into the CMDB?
We have decided that the more important thing is to have the business apps and their relations to each other and to the servers they are on etc but not the memory chip in the server. If we won't that detail then we launch (via a smart action) into HPSIM or SMS?
But there is of course no right or wrong answer - but 400 does seem excessive.
I cannot resist adding my two cents worth on the question of whether 400 attributes is too many or not.
I suppose that given the level of maturity of 99.9999% of IT organizations, the answer is probably yes.
However, the level of maturity of configuration management in IT is extremely primitive when compared to other industries, such as aviation, marine architecture, etc., where keeping configurations under control is more like a religion than a service management process.
We need much higher awareness of the benefits of more detailed configuration management, and much better tools to help in that management.
I can only praise the organization that works in this direction; however, don't try to bite off more than you can chew.