This post is for a customer fresh from an ITIL foundation course, looking for guidance or help with getting started with a Configuration Management Database (CMDB).
I’ll start with a reminder of what the CMDB is. It is a documentation for your IT infrastructure, describing how various parts (called Configuration Items, CIs) fit together to deliver services to customers. It typically shows dependencies between CIs, and carries a lot of business-related information in addition to the technical data you would expect.
It is an important underpinning resource, used in Change Management for example for performing important tasks such as impact assessment.
There is another discipline sometimes confused with this – Asset Management. This is where you keep lists of computers for reasons such as accounting purposes. In Asset Management you have lists of equipment, but these are typically not linked together – so you can’t use this data to understand how services are delivered to users.
Having given that definition, let’s come back to the subject of this which is getting started with a CMDB.
I’ll write in the form of Do’s and Don’t.
Do: Create your CMDB as part of a wider IT service management programme. In other words, what is your level of IT service management process maturity? Do you have an effective Incident Management process for example?
Do: Think very carefully how you will keep the data up-to-date. This may be your biggest challenge. The answer is to use Change Management to ensure that the data you are spending so much time to create is as accurate now as in six months.
Don’t: Necessarily start with desktop data. One thing we’ve noticed is a tendency for desktop equipment to be the first data entered into the CMDB, but you should ask yourself, particularly at the start ‘is this right?’. I’m not saying this is wrong, but just to stop and ask the question ‘what do I want to be in the CMDB and what is the best place to start’. I’ve blogged about this before in ‘What should be in the CMDB’ but you may want to start with your server infrastructure, particularly if the most important services you deliver to customers are server-based.
Do: Create your data in phases. If you are creating data for a complex infrastructure, one technique I’ve used is to isolate different systems and infrastructure (I’ll call these sub-domains), and to then concentrate on creating a representative model in the CMDB for each sub-domain. Doing this gives you a series of deliverable milestones, and allows you to perform checks and validation on each sub-domain as it completes. You can create sub-domains based in services offered to users, or physical location – whatever makes sense to you.
Don’t: Start before agreeing with interested parties what data will be held. For example, are you going to store warranty information (usually yes)?
Do: Be clear about who owns the data. Usually this will be your Configuration Manager, but it is important that the data has an ‘owner’ who will be responsible for it’s integrity and quality.
Don’t: Leave the ownership of the data to a group or to ‘the team’.
Don't: Limit what is in the CMDB to hardware Items. Instead, remember that CIs can be virtual, representing important entities such as database server instances, software firewalls and web servers.