Configuration management – or service configuration management as ITIL 4 now calls it – is the capability, or set of practices, that helps your organization to understand how your business services and processes are delivered using technology and the dependencies that underpin them. Configuration management is positioned as a key part of IT service management (ITSM) by best practice approaches such as ITIL. However, many organizations still struggle to succeed with it – often starting then losing steam due to the complexity and/or the competing demands for resource and attention from other ITSM disciplines.
In particular, many configuration management initiatives get stuck in the mapping out of the IT estate, including the relationships between configuration items (CIs). So, this blog looks at how a data model can help with configuration management – from configuration planning and baselining to control, verification, and audits.
The benefits of configuration management can sometimes be difficult to articulate – because configuration management generally doesn’t come with the quick wins associated with implementing, say incident or change management capabilities.
One way to make it easier for stakeholders to understand the benefits (of configuration management) is to include a data model when setting out your configuration plan. Where a data model is something that maps out the end-to-end services at a high level.
A typical model would start with the following items:
Done well, a configuration model will effectively represent data about the most common configuration items such as hardware, software, and services and provide a mechanism for linking that information to provide a complete view of all elements of an IT environment and how they affect each other. A data model will call out the key building blocks of each service as well as how they work together to deliver the agreed output.
A configuration management data model unifies the representation of configuration data. It’s designed to represent data about the most common CIs such as hardware, software, and services to provide a mechanism for linking that information for a complete view of all elements in an IT environment and how they affect each other.
As a starting point, the following attributes should be captured for each CI:
Also, make sure that your CI descriptions are clear so that your model can be understood by everyone with a vested interest.
When I’m creating a data model, I find it useful to map out my CI descriptions as follows – to show the appropriate business tower or IT stack, category, type, and description of each CI for clarity.
|Tower 1||Service||Business Service||A business service provided from one business to another or from one part of the organization to another. For example, customer services, order fulfillment, and reporting.|
|Tower 1||Service||IT Service||An IT service provided from IT to the rest of the organization to underpin business services.|
|The application components that make up business and IT services.|
|The infrastructure and hardware components that make up business and IT services.|
|The facilities components that make up business and IT services.|
So, you’ve captured your CIs, confirmed the key attributes, and called out what your top layer will look like. This will now enable you to represent your IT estate in a model similar to the following:
The key benefits of data modeling include:
What are your top tips for building a data model to help support configuration planning? Please let me know in the comments!