How to Use a Data Model to Drive Configuration Planning
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.
Here @OdedMoshe explains 'How to Use a Data Model to Drive Configuration Planning' including getting started and it's benefits. #business Share on XWhat’s a data model and why should you care?
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:
- Infrastructure CIs – the hardware hosts your application and service CIs such as servers, storage arrays, and network devices such as hubs, routers, and switches
- Service CIs – the service delivered to the end user for example file and print (servers, SharePoint, and printer hardware); or communications (email, video conferencing, and instant messaging)
- Software CIs – the software and applications that combine with hardware and facilities CIs to create the end-to-end service
- Facilities CIs – for example, data centers, generators, and fire suppressant and cooling systems to protect the hardware CIs and the services hosted on them.
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.
Getting started with a configuration management data model
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:
- The unique identifier and asset tag if appropriate
- CI type, e.g. server, network device, or software package
- Brief description
- Version number
- Support details – primary and second line support teams
- Vendor details
- License details
- Purchase date
- Owner
- Location
- Status
- Warranty details
- Mandatory relationships to other CIs
- The IP address (if appropriate)
- MAC address (if appropriate)
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.
Table 1: Example CI descriptions
Service Tower | Category | Type | Description |
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. |
Tower 1 | Application | Application Database OS Middleware | The application components that make up business and IT services. |
Tower 1 | Infrastructure | Server Storage Network Desktops | The infrastructure and hardware components that make up business and IT services. |
Tower 1 | Facilities | UPS PDU Generator Site | 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:
Figure 1: Example data model outline
The benefits of using a data model to drive configuration planning
The key benefits of data modeling include:
- Clearer scope – a data model provides a focus for determining scope. It provides something tangible to help business sponsors, technicians, and developers agree what is included and what could be covered via asset or inventory management.
- Consensus – models promote visual clarity around your estate making it easier for IT and the business to build a picture of key services among developers, customers, and other stakeholders.
- Clear nomenclature – a data model promotes agreement on naming conventions and business and IT terminology.
- A starting point for IT asset management (ITAM) – one of the biggest challenges around ITAM is identifying the individual software and hardware components that make up a business service. A data model allows you to map out an end-to-end service ensuring no components are missed or forgotten about.
- Faster incident resolution – by mapping out critical services you’re enabling your service desk to get ticket routing right first time, no more bouncing tickets to multiple teams until you assign it to the correct group.
- Better documentation – by accurately representing key services, you’re providing a solid basis for effective knowledge management and long-term support.
- Better understanding – by providing a data model, you’ll be enabling your stakeholders to understand configuration management and thus support their buy-in and planning.
What are your top tips for building a data model to help support configuration planning? Please let me know in the comments!
Did you find this interesting?Share it with others:
Did you find this interesting? Share it with others: