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:
- Identification (Baselining)
- Status Accounting
Let’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!