Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
· Home
· Content
· Feedback
· News
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: atifyna
New Today: 17
New Yesterday: 31
Overall: 231521

People Online:
Visitors: 112
Members: 0
Total: 112



Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

NOTE: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - What would be the granularity level to define a CI ?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

What would be the granularity level to define a CI ?

Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management
View previous topic :: View next topic  
Author Message

Joined: May 18, 2008
Posts: 1

PostPosted: Sun May 18, 2008 3:41 pm    Post subject: What would be the granularity level to define a CI ? Reply with quote

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.

Last edited by ireensl on Mon May 19, 2008 2:50 pm; edited 1 time in total
Back to top
View user's profile
Senior Itiler

Joined: Sep 16, 2006
Posts: 3597
Location: London, UK

PostPosted: Mon May 19, 2008 8:31 am    Post subject: Reply with quote

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
Back to top
View user's profile

Joined: May 08, 2008
Posts: 39
Location: South West

PostPosted: Mon May 19, 2008 5:57 pm    Post subject: Re: What would be the granularity level to define a CI ? Reply with quote

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.
Back to top
View user's profile MSN Messenger
Senior Itiler

Joined: Feb 23, 2005
Posts: 458
Location: London

PostPosted: Mon May 19, 2008 7:33 pm    Post subject: Reply with quote


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'.

Did I just say that out loud?

(Beige badge)
Back to top
View user's profile
Senior Itiler

Joined: Mar 04, 2008
Posts: 1894
Location: Helensburgh

PostPosted: Mon May 19, 2008 8:10 pm    Post subject: Reply with quote


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
Back to top
View user's profile Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management All times are GMT + 10 Hours
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003

Forums ©


Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.