CI level advice required

[Neil_123]

Hi all,

I work as Change and Configuration Analyst for a small company that provides web-hosting and Access Identity Management for the public sector. We have a fairly mature Change Management process but not very much in the way o f Configuration Management aside from a CMDB that is probably only 60-70% accurate and does not capture relationships between CIs very well.

My manager would like me to investigate a complete overhaul of our Configuration Management which may in the medium-long term involve a new CMDB tool. What I would like to know is if there are any similar companies out there that have gone through this process, and what CI level they settled on for their CMDB?

At present we only capture Server/Router/Switch level CIs, but I would like to expand this to include Staff, PCs, other Hardware CIs such as HDDs and NICs, building floorplans, SLA documentation and so on.

Am I being too optimistic in trying to include as many different CI types as possible from the beginning, or should I limit the CI level to what we currently have and make sure it is 100% accurate before moving on?

Many thanks

Neil

[UrgentJensen]

Hi Neil,

Don't manage what you don't need to or cannot do effectively/efficiently. Lots of people attempt to start Config thinking they'll have control over absolutely everything, but then start to realise what a b!tchin job that's going to be!

Do you have a business side requirement for metrics around CIs? Generally speaking it should hopefully align with whatever you define as services (like you'd put in a service catalogue) and don't manage what you don't really need to.

So the level of CI layers you need manage shouldn't really be more than what you need to feed back to the business and also support your Change Mgt process.


Another key factor is the data integrity. I would take the stance that if one true source does not exist for a particular part of the infrastruture, then forget it. You either have it or you don't. So this might cut out a few areas immediately.

Finally, I'd recommend that you do all this work before even thinking about tools because it might save you a lot of money by buying what you need rather than what you want.

Hope this helps,

Urgent
_________________
Did I just say that out loud?

(Beige badge)

[UKIT]

We have 2 CMDB's,one for servers and one network components.
Each Ci has an owner or team associated with it,in which they are responsible for its accuracy of the Ci data.
There are many fields within the CMDB that we use that need to be populated but its not that difficult to keep updated,as all changes go via the CAB anyway.
Server hardware config is key for our operation,so knowing how a server its setup is vital,should the need arise.
Only store the information that you think you need to start with and take it from there.
Having a technical background and now working as a Config Manager helps with what I believe should be listed in CMDB's.
I also get input from our technical teams as to what they want to be listed within the CMDB's as when there is a problem they are the ones that will be addressing the issue.Just knowing the physical location of a server,as in Data Centre - Cabinet number etc is key.A server that fails to come back on line following a reboot where someone needs to physically power cycle the server is a prime example.

[Favour]

Would it be right in saying that if I wanted to break down a critical service to a lower level that I will put the service as a higher level, then break it down to hardware, software, People and Documentation (SLA, OLA and underpinning contracts)?