CI scope/depth

[SteveK]

Hello all -

I'm just getting started on defining a set of CIs for my organization, which provides managed IT services in the commercial sector. I'm struggling with determining scope (where do I draw the line on what should be identified as configuration items?) and depth (how much information should be captured for a given CI?). The tradeoff, as always in data management, is between having enough information to be useful without having more than one can realistically expect to maintain.

What I'm finding in my research to date, is a general "yeah, that's a tough one", which is of limited value. Of course, I can find courses and consultants that promise to help, but I'm looking for some body of knowledge in this area, from which I can define my own requirements. Any ideas?

Thanks - SteveK

[Conexio]

I do not think vconsultants will help you except to either impart their own persoanl beliefs based on their experience, or reguritate your own beliefs in their own format - typical consultant addage "show me your watch, I will tell you what time it is."

In response to your question, it is very subjective to what you feel is an appropriate level of detail. There is no hard and fast rule. If you utilize software to track this information, such as LanDesk, it can capture to the very minute detail automatically, then you can report on the level of detail you want. if you want more information the future, the data is already there, you just select the additional pieces.

In the Service Support book offered by the OGC, page 164 offers suggested CI attributes.

The biggest thing to remember - CIs are NOT JUST HARDWARE. It should also be used for software AND people.

I am a former CIO turned ITIL consultant and can help you in many areas, including what you ask, but I fear you would be frustrated with the resulting recommendations of this specific area because it would be a regurgitation of what the people in your organization feel is appropriate.

[Guest]

When identifying CI keep in mind the main question: what information we will need to restore the system in case of ...degradation, disaster, etc. Hardware, software, docs, building blueprints, resources all became CI, to what level you want to go will depend on your own (your company) requirements.
The advantages to have a consultant: they did that before, they are armed with previous experience, they will save you time (resources).

[PSMC]

When identifying CI keep in mind the main question: what information we will need to restore the system in case of ...degradation, disaster, etc. Hardware, software, docs, building blueprints, resources all became CI, to what level you want to go will depend on your own (your company) requirements.
The advantages to have a consultant: they did that before, they are armed with previous experience, they will save you time (resources).

[rjp]

The ITIL framework stresses that one of the key failure points for configuration managements is poorly judged scope when undertaking the initial classification and discovery of CIs.

So make sure you get the scope question sorted first: And this will very much depend on who wants the information and why.

Is there a greater emphasis in your organization on plant management than say incident resolution?
Is this primarily to support Incident or Problem Management activity?
Is it being driven by the need for management reports - and are they concerned with reliability statistics or something else?

Obviously if you want to implement better plant management controls (maybe as a part of formalizing change management), then the scope will have to capture everything that will be touched as a 'single unit' - and the dependencies between them. but you may be in a position to start with the 'machine room' and leave the desktop alone for the time being. (Horizontal scope versus vertical)

If you are primarily looking to support incident management then you can still get good returns from a shallower scope and judicious application of the 80/20 rule.

One thing to think about:

Take a leaf from object-oriented methodology and don't loose sight of the difference between developing an intelligent an informative schema (classification system for your CI's) and a full asset register that contains records for every instance of a CI in the infrastructure.

Just like abstract classes in software, recording incidents against 'classes' of CI's can return a lot of very useful service oriented information. For example if you have a particular problem that occurs with a model of monitor, you can record that known-problem and the standard response to it when encountered against it as a 'class' of CI - then a technician working on an incident can still access that information based on the model of the monitor they are working with. And that is without there needing to be say 1500 records in the CMDB for each model of that type.

Service to CI mapping is important to - and the Service Catalogue can play a clarifying role when trying to decide what to record as CI's and how to organize that data meaningfully. When developing our current catalogue we actually started by having the highest levels of CIs possible - one general service to the business (ie Network Connectivity) equaled one CI. Later that could be broken down into sub-nets, switches, DNS servers, and so on.

The gains, however simplistic this might sound, were immediate and measurable.

(And as I said in a different post Configuration Data is not operational data per se: most technology-towers keep adequate operational information and can see what's going on from an operational point of view. So, if they are effective, why give them another way to do what they already do well. What usually missing, and what CMDBs are all about (IMHO) is providing meta-data, information that allows for control and auditing of operational decisions - not technical support for the operations themselves. it is the ability to simplify and abstract that makes a map powerful - a map that is as detailed as the terrain offers no analytical advantages.)

So prioritize your objectives in terms of the use the data is to be put to, and start with a scope aligned to the highest priority outcome. You can always add detail later.