Following on from our previous article, this week we’ll take a look at Configuration Management baselining and control.
First up we have the identification or baselining step in our Configuration Management process. This is a baselining process, taking a snapshot of our critical services and their key dependencies so that we know exactly what makes up the service. The purpose of a baseline is to take a measurable part of the service so that it can be added to a CMDB (Configuration Management Database) or CMS (Configuration Management System). As it’s a snapshot of the state of a service at a point in time, it can be used as part of Change Management as if the service has changed there will need to be a valid, authorised RFC against it as well as being a stable reference for future planned works.
So how do you carry out a baselining exercise in real life? My advice? Start with your most critical service. You know the one. The system that if there is even a hint of slowness or performance issues your Service Desk is inundated with calls and the angry mob are off out finding their flaming torches and pitchforks. That’s the one. Start by talking to everyone involved with the service from support teams to the business. If it requires third party support, consider asking your supplier for their guidance for what data should be captured in a CMS for example if you ever need to log a support call with them, what are the top ten things they will ask for?
Don’t try to capture too much data at first – you can always build things up later but if you try to go into too much detail when starting out you might run out of time and money. Also bear in mind, the more detail you capture, the more work it will be to maintain. As a starter for ten, here are some useful CI attributes to capture:
- Unique Identifier
- CI type eg server, network device, software package
- Version Number
- Support Details
- Vendor Details
- Licence Details
- Purchase Date
- Warranty Details
- Relationships to other CIs
You also don’t necessarily need an expensive tool – I used to work for a small bank during its UK start up and the IT budget was really tight. We desperately needed a CMS to support Incident and Change Management but didn’t have a tool. I went round to every support team and techie I could find and used a spreadsheet to build up a basic CMDB of our key services then created a business case over the following few months to demonstrate the benefits (I was able to demonstrate tangible reductions in Change failures and Incident resolution times) to secure funding for an ITSM tool that included a CMDB.
Remember any CMDB, no matter how basic, is better than nothing. If you are going down the spreadsheet route then talk to your techies. If discovery tools such as SMS or Alteris are in place then they could be used to help you build a basic CMDB.
Configuration Control goes hand in hand with Configuration identification and baselining. Having control in place means that there is appropriate support in place to ensure that when a CI (Configuration Item) is updated, that the CMS is updated so that what you have in the CMS matches exactly what you have in your production environment. Nothing will make your Configuration Management process fail quicker than your CMS having incorrect or out of date information so control is a critical aspect of Configuration Management.
Work closely with Change Management to make sure your processes are aligned; for example you could put a process step in place where a Change can only be closed off as successful when the CMS is updated. Sounds basic I know but you would be amazed at how many times I’ve seen people forget to update documentation following Change activity so if you have it formally built in to the process, nothing can be missed or forgotten about. Also, if you’re not part of the CAB meeting, get yourself invited so you can add subject matter expertise around service relationships and dependencies during impact assessments.
Work with Change Management to consider putting Change freezes in place during key process points such as baselining or audit exercises so you’re not trying to hit a moving target. Believe me, there is nothing more stressful in an audit situation than having a last minute panic about the version information of a CI being up to date following a Release the previous night.
These are our top tips for Configuration baselining and control. What do you think? Let us know in the comments!