Configuration Management How To (Part 2)

Following on from our previous article, this week we’ll take a look at Configuration Management baselining and control.

Configuration Baselining

2561885967_f5f0be5834_z

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
  • Owner
  • Location
  • 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

3812759931_8aa94e57bb_z

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!

 

Image Credit

Image Credit

Configuration Management How To (Part 1)

Overview Of Service Asset & Configuration Management

Service Asset & Configuration Management (SACM) is the process responsible for ensuring that the assets required to deliver services are properly controlled, and that accurate and reliable information about those assets is available when and where it is needed. This information includes details of how the assets have been configured and the relationships between assets.

Done correctly, Configuration Management is a key enabler for resolving Incidents, identifying the root cause of Problems, impact assessing Changes and building the technical layer of a Service Catalogue. It’s also the process that tends to make people panic because of all the databases, information systems and scary terminology; so here is our panic free guide to Configuration Management. Configuration Management is made up of the following steps and we will look at each one in turn:

  • Planning
  • Identification (Baselining)
  • Control
  • Status Accounting
  • Verification


Configuration Planning

7802754212_0fd2e22154_zLet’s start with the basics. Configuration Management is one of those processes where you really, really need to have a plan. I’m not talking any old plan either; I’m talking Hannibal from the A Team level planning. Why is planning so important? One of the biggest reasons Configuration Management fails is because people try to do too much so setting the process scope is a key activity.

Let’s start with the inventory layer. Inventory Management takes care of consumables; keyboard, mice, USB sticks and SecureID cards. Stuff that needs to be tracked for monetary value and to make sure it’s in stock but that’s about it. The next layer is Asset Management. Examples of assets include PC’s, Laptops and printers. Stuff that we need to keep track of for monetary reasons, to make sure they’re in stock when needed, locational info and how they are supported. The final layer is Configuration Management. Items under the control of Configuration Management (CIs) are the big chunky items that make up your critical services. Servers, network devices and software applications should all be under the control of Configuration Management to make sure they are managed, supported and subject to the appropriate Change control.

The plan should also explain any naming conventions or nomenclature. Confused? Every CI or item that is under the control of Configuration Management should have a unique name or identifier. When I’m tasked with implementing a Configuration Management process from scratch I try to use a naming model that will make it easy for the CI to be identified so I tend to use the following:

Type of Service – Location – Level of Complexity

So a WinTel server based in Dublin requiring third line support would be WinTel1234 – DUB – L3 and a business spreadsheet located in London requiring first line support would be Exl-LON-L1 and so on. In terms of naming conventions; it doesn’t matter what framework you use, as long as everything has a unique identifier. When I worked for an investment bank in London, the naming convention was food based so all WinTel servers were named after Italian food, all UNIX servers were named after Chinese food. Another example is from a firm that I worked for in Reading; all WinTel servers were named after characters from Terry Pratchett books and all Network devices were named after monsters from ancient Greek mythology. Both worked really well and as an Incident Manager it was pretty hard to get stressed during a Major Incident when someone shouted Rincewind’s fallen over again!

The plan should include a reference section. When you’re building a CMDB you will be talking to support teams, service architects and project managers. Ensure that you capture the source of the information whether it be from a Service Catalogue, support documentation or even from SLAs so that it can be verified before it’s placed in your CMDB.

Does your organisation have a Configuration plan? Let us know in the comments!

 

ConfigEnterprise Service Management Webinar Module 3: CONFIGURATION MANAGEMENT

Don’t forget to join us for our 3rd webinar of the series – Configuration Management on 31st March, 2pm GMT. Register here!

 

Image Credit