One Pot Meals, The CMDB

If you have a Configuration Management Database how up to date is it?  Is it taken seriously by your organisation? More importantly, does your organisation understand it?

The backbone of your CMDB is more than likely going to be your windows devices, or more accurately workstations, laptops, tablets (x86/64) and servers that run with a windows OS.  But what about the none windows servers, switches, phones and other mobile devices?  In-fact where do you or your organisation draw the line?

The truth is that Configuration Management is one of the hardest processes to implement and maintain.  It requires the full support of the organisation.

If your CMDB and Config Management is going to fail it is largely down to doing to much to quickly.  Think of this as a giant one pot meal and everything goes in at once.  Try to get everything in the pot is going tend in failure.  The Configuration Manager will be spending all their time chasing issues and trying to embed the process.  Worse if the implementation of the CMDB fails it will have a knock on effect on the processes it is supposed to support and be very difficult to make right.

So try small steps, introduce certain elements of your infrastructure into the CMDB and under the remit of Configuration Management. Get that right or up to an accepted level and then move onto the next bit.

While the Windows servers are being introduced into the CMDB the Configuration Manager can look at other device types and finding ways to get the data into the CMDB, learning important lessons from the current deployment, establishing standards and procedures.

Be sensible, do not try to get everything into the system at once and then you will stand a chance of getting your CMDB off the ground and robust.

Why is Change Management so important?

Why is Change Management so important to your organisation?

I could go in to the obvious; managing change, reduction and understanding risk but I won't.

Change Management is the linchpin for most ITIL framework frameworks.

For example look at Configuration Management, without Configuration Management and a Configuration Management database all processes will struggle to be embedded;

• Problems need to be raised against something, a Configuration Item for instance without a CMDB what are you raising you problems against?
• Incidents also need to have the potential to have a CI associated with it, especially in support of problem management.
• Release and Deployment, what is being released and deployed?  Not in the CMDB? but it will be, if it exists.
• Change Management, hang on Change Management?  Yes, ideally we want to raise a request for change against a CI.

Change Management requires Config Management? well yes eventually but you can have Change Management without Config Management but not the other way round.  This is because any effort into getting a CMDB and getting it up to-date is all going to be in vain as of the first unrecorded change. How do you manage the transition of a Baseline CI through change and then released back to BAU?

The short form of this is that without Change Management the Config Management process will never be able to keep the CMDB up to-date. Any process that requires an accurate, up to-date CMDB will not be effective.

So Change Management is important.