help needed for defining CI

[poolakb]

Dear all,
I am quite new to this topic and to this forum as well. For a client, we have to suggest the CI for their IT Infra – covering mainly servers (Unix and Wintel), switches, applications (e.g., SAP) and procedures/doc (e.g., vendor contract, SLA, support contact, etc.,).

Currently, we have a discovery tool to scan all the servers (at L2 level) and switches and another asset scanning tool for the same set of items. However, racks, power need (per rack) are not covered by any of the above tools.

We have fair idea of what we can do but very little about the CI that we can start with for a reasonably ok setup to support change management which is the main purpose of the CMDB setup.

Can you share your experience to help us forming the CI that we can propose to client? Also, if there is any document that talks about ‘standard’ CI for data center equipments (server / network-eqpmt / apps / procedure-doc), that will also be very helpful for me.

Thanks for a quick help, it is kind of urgent...
Cheers,
Poolak

[Diarmid]

poolak,

CIs are "horses for courses" (which is another way of saying "it depends").

CIs exist to help you manage your service infrastructure and therefore you need to set them up at the level you will manage them. If there is a document for "'standard' CI for data centre equipments", then it is either wrong or it is too generic to be used "off the shelf".

Ask yourself what information will change management need about the infrastructure, what will incident and problem management need, what will capacity management need, availability management, continuity management, implementation management, what will you need to know when you are designing a new service, when you are supporting a service...

It is all (mostly) explained in the ITIL books. Have you read them?

One thing I can say with confidence is that it is better to start simple, keeping your design open to extension in any direction.

Does your client know the level of your understanding of service management?

[poolakb]

Thanks Diarmid, I will keep in mind this one.

Actually, I have few subject matter experts for this and surely they can get this done. My intention was to find some quick solutions for defining the CI (as generally does for servers for other places). With my 'limited' knowledge, I assume that the basic minimum CI for server will be more or less similar in different setups.

Thanks anyway,

[paulfixter]

You have got to decide to what component level you want to manage.

We only go down as far as "Desktop PC" for example, but other organisations will go down as far as components such as hard drives, DVD drives etc.

We also don't record keyboards and mice as CIs....but others do.

Bascially you will have to make the decision based on how far you want to drill down, and also of course bearing in mind what VALUE you will get if you drill down quite far.

Hope this helps
Paul

[Wisey]

Also, you will need to define the roles and responsibilities on the CI owners / contacts / supports cross the CI life cycle.

Naming and version standards are need to be defined as part of the procedure guide / policy.

avoid too many layers of dependencies and un- incontrollable details of CI attributes.

-----------------
Wisey

ITIL V2 Service Manager
Configuration Manager

[DYbeach]

Relationships is what it's all about (well, largely), and you need to have this focus from the get-go

[BobSchuwob]

Some ideas:

1. Start with the services. Define these as CIs. Then think about what supports them. These are the next CIs. Then think about what supports those CIs and so on until it gets silly. Then stop and go back one step.

2. Look at the things RFCs are raised for. The objects of change are CIs.

3. Just define what you think should be a CI in your policy and go with that. Apply Continual Improvement as you learn more and more. But you shouldn't maybe apply Continual Improvement to a Policy, so document the CIs elsewhere.

[ReleaseLeeds]

You've also got to come up with a decision on that level of granularity that is 'maintainable' moving forward. For example it's pointless defining a level down to even modules of code or operator instructions. (like my previous very large employer had) If you work in a small company with very little support staff running your ITIL processes then a very detailed CMDB would surely become a maintenance headache, if it gets updated at all. (which would defeat the purpose of course)

In my current a lot smaller company (when compared to the massive previous employer) we have decided to go down to only a level of server which will suit us so far as our current ITIL processes are very immature with the exception of Indident Management. Once we have that CMDB established there's a chance we may go lower than server level, but I doubt it.

Horses for courses I suppose is my general point!