ITSM Basics: How to Do Configuration Management – Part 2

Last week, in Part 1 of my two-part series on configuration management, I covered what configuration management is and the importance of planning, including scope and scaling. Now, in Part 2, I look at the configuration management disciplines of identification, control, status accounting, and auditing.

Identification/Baselining

Once you have your configuration management plan agreed and in place, it’s time to start phase two of your configuration management initiative with identification and baselining.

Baselining is taking a snapshot of your infrastructure so you know what you have and where it is at a certain point in time. Your baseline can be used for comparison purposes, e.g. “our estate has expanded by over 20% this year generating an extra 2,000 changes.” And once you have your baseline, you should ensure that any supporting service level agreements (SLAs), operational level agreements (OLAs), and underpinning contracts (UCs) are also linked (to your IT infrastructure and services) so that the way your key services are created and supported are formally agreed by all vested parties and can be managed under change control.

When carrying out your baselining, start with one service and map all of its components. Store the information centrally within your ITSM toolset if it has an integrated configuration management system (CMS) or configuration management database (CMDB). Alternatively, simply use a spreadsheet or database.

It’s important to consider and agree who can update your CMS/CMDB during baselining, for example should it be just the configuration manager (it’s resource intensive, so this could be a possible single point of failure) or technical teams as well (there’s the potential for error but it puts less pressure on the configuration manager).

Change Control

The next stage of your configuration management initiative should be control and by this I mean change control, i.e. using change management as things change. You will need to work with change management personnel to ensure that everything under configuration control is covered by the corporate change policy. Ultimately, configuration management can’t function without change management because without proper control, your CMS/CMDB could be out of date within minutes and you’d be chasing a constantly moving target.

In terms of toolsets and records, make sure your configuration items (CIs) are linked to services so that it’s easy for the person raising a request for change to select a service and also carry all the underpinning CIs into the request. Configuration management personnel should make every attempt, even attending all change advisory board (CAB) meetings if necessary, to ensure that the CMS/CMDB is updated to reflect all change activity.

My tip is to include a mandatory step in the change ticket to ensure that the CMS/CMDB is updated before the change can be closed off as successful.

Status Accounting

Next up is status accounting. This is the part of the configuration management capability that looks at where a CI is in terms of its lifecycle against the previous baseline. It’s important to ensure that you have an acceptable list of lifecycle statuses in your configuration management policy to ensure that the stages that each CI will go through is documented, agreed, and understood. Stages could include:

• Planned
• Order raised
• Delivered
• Test environment
• Live environment
• Retired
• Disposal

Auditing

The final capability is verification and audit – also known as ”trust but verify.” Put simply, the audit process is there to ensure that what we have in our CMS/CMDB matches up to what we have in real life.

Regardless of the size and complexity of your organization, you need to have a plan for carrying out audits. Is there an existing tool that you can use such as Symantec Server Management Suite? Are physical checks required to ensure that everything matches up? What about regulatory requirements? If you are ISO 20000 certified or have legal requirements under the likes of IL3, BASEL 3, or NGN224, then you will have to be audited by an independent third party.

Every organization is different but as a bare minimum, I would ensure that several spot checks are carried out on critical services every month and that a full, internal audit is taken every year.

Create a configuration audit exceptions log so that any exceptions can be logged and corrective actions assigned and completed. The log should contain the following information:

• Date of audit
• Service and CI type of exception
• Owning senior management
• Task to remedy
• Task owner
• Due date
• Status

If you have a risk, regulatory, or audit department, then ask for their help and support with this. It’s also good practice to run an internal audit before an external audit so that any “gotchas” or oversights can be identified and dealt with before it becomes an official audit finding or failure.

Configuration audit tasks should ensure that:

• All CIs in production match what is documented in the CMS/CMDB, both numbers-wise and in specifications
• Support documentation accurately describes the CIs
• All change requests linked to a CI have been approved and closed, and any CMS/CMDB updates captured
• Naming conventions have been applied consistently

Again, the configuration management link to change management is vital here as a change freeze could be requested to support critical services in the event of an audit.

Final Thoughts

Hopefully we all know that having a proper configuration management capability can save time, money, and resources. Implemented effectively, not only can configuration management speed up the resolution of incidents and problems, but it can also prevent them by making sure we get it right the first time, change-wise.

So configuration management done properly should be like spending a cent to save a dollar. If it’s like spending a dollar to save a cent then I suggest you look again at your configuration management practices and data use cases.

Well, this two-part blog has been a long read, but hopefully it has you thinking about how fundamental configuration management is not only to help you resolve day-to-day incidents; it’s also to assist change managers in the prevention of avoidable incidents by creating more robust risk and impact evaluation, and helping to reduce time and costs while increasing value to your IT organization.  

Does your organization do configuration management? If so, I’d love to hear your best practice tips for success.