What would be the granularity level to define a CI ?

[ireensl]

What would be the granulity level to define a CI ? As a fresh ITIL practitioner I had a brainstorm after the issue raised by one of our manager.

CMDB definitely a storage with huge information of IT infrastructure – software, hardware, document. The analysis would take time to measure the depth to declare a CI. In such case, where one looking for an urgent implementation of CMDB what would be the minimal to maximum level of CIs ?

Common sense would tell to consider the urgent CMDB as a RnD. Change Management would perform a major role here to declare a CI. It is actually the issues , either software or hardware, a Change Management is dealing in daily operations; e.g. if it is a software module related change then Change Management can easily mention the component or module to CMDB as a prospective CI. There could be a sub-category of a CI, i.e. if the principal CI is a Module then the sub-CI could be its components.

Nevertheless, a 100% accurate CMDB implementation is a consistent and gradual process.

[UKVIKING]

The granularity of the CIs in the CMDB would depend on what your company . organization would want to track

For some - the server details

for others the server - os/version, etc etc etc

it is also about whether you want to cover everything thereby covering nothing
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[kinger]

Something to consider is if there is anyhing out there that can help you.

I've found combining some basic level CMDB information with a well implemented discovery tool for example is very useful way of managing detailed information on CI's.

The easiest example I awalys consider is location of a CI. Imagine you're referring to a desktop PC. Would you store the site, floor, department, bank of desks, or specific desk?

It all depends on your company as VIKING said, if it has floors of 50 PC's, it's probanbly not worth the effort of storing the location information to anything beyone floor level, as finding a machine amongst 50 others (assuming the assetting is done well) is not a problem. However if you have hundreds of machines on one floor then you may have to break it down further. The other consideration to make is how difficult the information would be to manage. In the same scenario, it would be of no use storing the PC's to desk level if you were moving hundreds of PC's around every day, (or the staff were in the habit of moving them themselves) as the overhead needed for Configuration Management would possibly outweigh the benefit it provides.

[UrgentJensen]

Hi,

Building on those above; your CIs should relate to your 'services'.

E.g. If you are advanced enough and have a formal Service Catalogue then the CIs you'd want to manage would be the ones that underpin the delivery of each service to the customer and therefore you can link perfromance of your Config Mgt function/process somewhat to the metrics set against those services.

And yes, with a service catalogue you're going to have a customer facing one and a technical one because customers don't necessarily want to know about your convergence of infrastructure, they just want to know that email will 'get here'.

UJ
_________________
Did I just say that out loud?

(Beige badge)

[Diarmid]

Hi,

what is "an urgent implementation of CMDB"?

The things that make it urgent should also dictate the content and functional scope.

If your urgency is willing to sacrifice proper planning, analysis and design then you must budget to start all over again very soon.

There is no issue about granularity before you start. Granularity is self-defining from your identification of what you require to control and granularity varies all over your CMDB because some entities have less hierarchic structure that requires control than others.

If your software tool will not let you grow your hierarchies and relationships over time, then you are in trouble. So you can start at any level you want and grow the detail when needed.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718