You have a tool, you’ve populated a CMDB, and you’re using a set of configuration management processes. But what’s next?
In this blog I’ll explore how you can take your implementation of configuration management to the next level, maximising the return on investment and the value to your organisation.
Why do I need to do more?
You might believe that your CMDB and configuration management maturity is already good enough. You might even have self-measured it as part of a wider assessment of IT service management maturity. If so, that’s great – but can you quickly and honestly answer questions like these:
- “What value does the CMDB provide to the organisation?”
- “Is configuration management meeting its objectives?”
- “Are we getting the most out of our investment?”
- “How much money do we spend on configuration management?”
- “Does the CMDB provide all of the data required to operate IT?”
- “How good are we at configuration management compared to other organisations?”
Best practice configuration management is so much more than just following processes. Let’s explore this in more detail.
Getting stuck in a rut
Most implementations of configuration management are done as a project which ends when the CMDB is created and populated, processes and procedures are defined, and responsibilities for operating them are assigned.
Routine then sets in – more data is loaded into the CMDB, updates are made, reports are produced, audits are conducted. If you’re not careful this becomes the norm, with a belief that configuration management is working fine. But how do you know it is?
What can happen over time is that the contribution of configuration management to the business steadily declines. It becomes a self-centred overhead, mechanically executing the processes but losing touch with the benefits it was intended to achieve.
So what can be done about it?
How to release the value from your CMDB
You’ve probably already invested a lot of time, effort, and cash on your CMDB implementation. You will be getting some benefits from it now – most organisations see immediate improvements in how service management operate – but a CMDB can always add much more value. The challenge is knowing how to go about releasing it.
The best way to ensure that you achieve the highest possible return on the initial investment is to use a tried and tested improvement approach. This uses three primary stages:
- Where are we now? - the ‘As is’
- Where do we want to be? – the ‘To be’
- What steps do we need to take to get there?
This is an opportunity to not only improve how you do configuration management, but also ensure that the CMDB can sustainably support real business improvements, both now and in the future.
Stage 1 - Where are we now?
The first step is to conduct reviews to find out where you are now.
Spending time up front on understanding the current state from a wide range of perspectives will help you focus your improvement activities on what really matters to your organisation.
This first stage uses different techniques to review, understand and document the current state of configuration management, including:
- Achievement of desired outcomes and benefits
- Configuration management process scope and maturity
- The accuracy and integrity of the CMDB
- The quality of the data within it
- The current and future needs of customers, internal and external
- How the CMDB is used
- The level of automation in place
The three sections of configuration management
For all but the simplest CMDB implementation, it’s a good idea to split the review stage into manageable chunks.
A CMDB does not exist in a vacuum. It needs data inputs and must provide information, so the review of the current situation must always include these areas.
Splitting the initial ‘as is’ review and the subsequent stages into these following sections can help to provide the necessary focus:
A CMDB has no purpose unless you fully understand:
- who needs to consume the information provided by it
- what data and information they want
- what do they use it for
- how would they like to receive it
Knowing the answers to these questions is fundamental to delivering value to the business.
Hopefully you captured these before you started your implementation, as they should always drive the design of a CMDB structure and contents. If you did, then now is a good time to review then with the users, customers, and stakeholders. Their needs will always change over time as the business evolves.
If you didn’t then you might have to be prepared for major re-engineering of your CMDB!
Remember that the consumers can be from all parts of the business, not just IT and service management.
These are the processes and practices at the heart of configuration management. Best practice guides like ITIL provide a useful framework, including
- Status accounting
- Verification & Audit
I expect that you considered all of these when you did your CMDB implementation, and wrote them up into process documentation - but since then have you gone back to each of these steps and reviewed how effective and how used they are?
Many implementations start with the best of intentions, but as the workload increases the scope of CM activities often reduces, sometimes leaving just Identification activities with a bit of control provided by Change Management. Hence it’s always a good idea to hold a review of process take-up and maturity.
All data in a CMDB comes from somewhere. There are many different types of data source, including:
- manual records
- discovery tools
- specialist tools
There will be different techniques for extracting the data required from each of these sources, but some common requirements apply to all of them. You should understand, record, and maintain:
- Who is responsible for providing the data?
- Who is responsible for the accuracy of the source data?
- Where does the data come from?
- How reliable is the data?
- How is the data provided?
- How are changes in source data notified?
Without this understanding the data in the CMDB will soon become out-of-date. Decisions rely on that data. Inaccuracies can and do lead to:
- Unexpected service outages
- Frustrated service desk agents
- Risk of prosecution for licence compliance issues
- Unnecessary spend
Useful tips for the ‘Where are we now?’ stage
A full explanation of everything you should do in this stage could fill a book! – so here are just a few useful tips for how to get the best outcomes from the review:
Revisit the benefits
The expected benefits from configuration management should also be used as a basis for reviewing the effectiveness of the current arrangements. These should have been captured as part of the initial implementation, but it’s a good idea to revisit them as expectations often change once the CMDB has been used for a while. e.g.
- Improved incident resolution time by having access to useful data
- Knowing the impact of taking a system down during the working day
- Reduced service outages
- Increased protection from cyber attack
Metrics should always be defined and implemented to demonstrate achievement of these benefits over time.
Review use of the CMDB
It is important to review CMDB use and perception with the identified information consumers, identifying potential areas for improvement, including:
- Which business processes use data from the CMDB?
- Are consumers relying on data from alternative sources?
- What is the consumers view of data accuracy and relevance?
- How well is configuration management integrated with other ITSM processes, especially incident management, event management, and change management?
- Are there any CMDB service levels, and are they being met?
Review data sources
The ability to accurately and efficiently capture and load data into the CMDB is critical for success. How this is done now should be reviewed and assessed, identifying opportunities for improvements such as:
- Automated discovery solutions
- Tools that can verify data integrity before load
- Integrations with data sources
- Generic spreadsheet loader
One thing to be aware if is that data sources can change over time, as the provider areas evolve new ways of working and implement new tools. For example, a software development team may have adopted a new approach for managing code configurations. Your review of the current situation should therefore include a review of all provider areas.
Review process maturity
Maturity of process-based models is typically done using an approach based on the Capability Maturity Model Integration framework first developed in the 1990s at Carnegie Mellon University in the 1990s.
This widely used framework evaluates activities against 5 sequential levels of maturity to provide a holistic view of how well you’re doing against best practice.
It’s not enough to just ask ‘how mature is your process’, as this will always give a false picture. A good approach is to use the services of an organisation experienced in conducting maturity assessments for configuration management, as they will have a model that will give a true reflection of how well you’re doing.
Review the CMDB content
The contents of the CMDB should be subjected to a technical review, giving attention to:
- Data quality: Check for widows, orphans, and duplicates
- Service/application maps: Has every application been mapped to the services that it supports?
- Data dictionary: is a standard vocabulary used
- Database normalisation: How have tables been used to split the database for clarity?
This type of activity needs resources with skills and experience in database design as applied to configuration management.
Review the CMDB structure
The CMDB structure and configuration management processes should be reviewed to determine if they can meet the needs of the consumers and deliver the desired benefits efficiently and effectively.
To deliver the best value CMDBs should include data on many types of configuration items, not just physical components. The scope should include everything that’s required to deliver the IT services, including:
- Physical CI’s – including servers, desktops, laptops, mobile devices, applications, applets, networks, and components
- Logical CIs – including the service catalogue, service desk, facilities management, contracts, process documents
- User/Support Mapping – Mapping support groups and users to physical and logical CIs
- Cost Modelling – cost models that link the other CI dimensions
Stage 2 - Where do we want to be?
This stage uses the outputs from the previous stage to define the ‘to be’ situation.
It is crucial for this stage to be driven by the needs and strategy of the business, as well as those of the IT organisation. If this isn’t done, configuration management can become a self-fulfilling prophecy, with limited business value.
The precise content of the ‘to be’ model will depend on what these needs and strategy are, but here are some useful ideas:
Golden concepts of CMDB design
Adopting some simple concepts can help to maximise the benefits from a CMDB:
Only store data and information that is useful
It is very easy to include reams of data just because you have it. Discovery tools often encourage this bad behaviour, capturing large volumes of data from within the inner workings of PCs and servers, most of which you will never use but will still need to keep up-to-date. Check that all configuration items and attributes have a use.
Keep the design a simple as possible
As the complexity of configuration models and processes increase, the ability to understand, use, and maintain them declines. Using graphical representations can help to achieve simplicity.
Remember that everything you store must be kept up-to-date
Once data is loaded into a CMDB it must be accurately maintained. Relying on change management processes is unworkable for large volumes of volatile data such as:
- Application release version
- Anti-virus patch level
- Operating system patch level
- Network routing tables
User stories are a requirements definition technique borrowed from Agile. They are a great method for defining the needs of consumers in an understandable form.
Each user story is a sentence written from the perspective of a user, setting out what they want from the CMDB. They describe the ‘why’ and ‘what’ from a value perspective.
User stories can be used to test the design and operation of the CMDB and the configuration management processes. e.g.
“Before I take a server down for maintenance, I need to know which users will be affected”
“When a user reports an issue to the service desk, I need to know which versions of software are loaded onto their laptop”
“I want to know what the full IT costs are for supporting a particular business function”
Integration with Agile & DevOps tools
Many of today’s developers rely on tools that have their own configuration management capabilities. E.g.
GitHub: Cloud-based service that helps developers store and manage code, and track and control changes.
Chef: Infrastructure configuration, deployment, and management
Puppet: Manages an organization’s IT inventory
AWS OpsWorks: Automates application deployment, configuration, and operations
Whilst it’s possible to extract data from tools like these and other data sources into a CMDB, trying to keep it up-to-date can be a major challenge, especially when the data changes frequently because of rapid release cycles.
One way to avoid duplication is to build ‘read’ interfaces between the CMDB and these data sources, interrogating the data only when required, instead of copying it. This ‘federated CMDB’ approach allows service management staff to access up-to-date data from the CMDB, and IT teams to continue to use their specialist tools.
These special attributes for CIs can be very useful to record in the CMDB, avoiding the temptation to store the information elsewhere:
Data source: This attribute records where the data comes from. This can be the data owner, or the original source of the data such as a manufacturers data sheet.
Data confidence: Not all data is 100% accurate. Decisions will be made on CMDB data that could be critical to operations. Recording an estimate of the level of confidence in the accuracy of the data can help informed decisions. This approach can also help target improvement and audit activities.
Data volatility: Some data, like PC model, never changes. But some does. Noting which data is likely to change can help to identify what needs to be under the scope of change management.
Stage 3 - What are the next steps?
The next steps are always fully dependent on the previous stages, but whatever these are it is crucial to get buy-in from all those involved in the end-to-end process, including the stakeholders who are the customers of configuration management.
Improving configuration is never a trivial exercise and won’t happen overnight. Spending time on the discovery and design of the future state will always give the greatest benefits. The stages I’ve provided here should give you some ideas, but there’s lots more to achieving success.
How long it takes and how good a job is made depend entirely on the skills and resources available. Most organisations need help from someone with experience, but don’t delay – with help and thought a CMDB can transform the delivery of IT services and the value provided to the business.
Kevin Holland, ITIL Master, FBCS
Want to know how to build your CMDB in 12 steps? Join us for a free lunch and 30 minute webinar on 24th March - CLICK HERE to join!