I have worked with many organisations who set out on the journey of building the perfect Configuration Management Database (CMDB): a single entity that contains everything they could ever want to know about their business, services, IT equipment, statuses, finances, projects. It can seem like a daunting experience and whilst the ambition can seem admirable, the sheer scale of the task often puts off many from the investment and effort needed to achieve such a mammoth task.
Having been working in this area for many years now, I wanted to share some of my key principles and starting points for building a functional and useful CMDB that can mature through standard business practices and Continual Service Improvement.
Understand your scope
The downfall of many when starting to take control of their Configuration Items (CIs) is ending up confused and clouded by data overload. By looking to take control of all the data available in one swoop it is easy to become daunted or overwhelmed by the sheer scale of the challenge. This is where defining a very specific (and ideally limited) scope early on is important. Closely managing the implementation can help ensure the CMDB starts from a position of accuracy and confidence, ultimately allowing others to see the vision and benefits which reliable data can bring and encouraging them to invest in helping achieve the common vision.
I would recommend initially focussing on things that can easily be validated. Discovery tools such as SCCM or Solarwinds are of huge benefit as they can identify devices that are connecting regularly to your network and offer a large number of attributes and characteristics of a CI quickly and efficiently. Alternatively, by tracking what is connecting to the network regularly, you can highlight devices in your CMDB that may have stopped auto-discovering, proactively identifying potential issues within the network or even highlighting uncontrolled change. Discovery tools can also detect relationships between CIs, which will come in very handy as the CMDB evolves and you start to think about service mapping.
Make use of the CMS
Do not forget the ITIL principle of the Configuration Management System (CMS). ITIL describes the CMS as a set of tools and databases that are used to support service assets and manage the IT service provider’s configuration data. This means we do not necessarily need to bring in data to our CMDB that is part of the CMS, especially if the data is going to be more accurate or real time if held within its original data source. Information about available memory or IP address in a dynamic environment might actually be reducing your confidence in the accuracy of data within your CMDB if it disagrees with other elements of your CMS.
Keep it simple
The CMDB should be a utility to your organisation that helps describe your technical environment in a relatively straightforward way. This is why it is key to make sure it uses simple and easy-to-understand terms and reference points. Helping your organisation achieve a common language is a key goal of the CMDB, making the available information accessible to technical and non-technical users alike. This is another reason to start small and increase visibility and scope over time.
Think of the inputs and outputs
One of the final considerations with working out how to build and what to put in your CMDB is to think about what you want out of it. If capturing a particular value does not provide any benefit, and you are only doing so for vanity, why do it? By working with the key stakeholders of the CMDB you can focus on actively pursuing the CI Types and Attributes relevant to your business, and this will ensure that no effort or bandwidth is wasted on gathering data which won’t be actively used.
Focusing on the outputs can also help bring you back to the question of inputs. If our stakeholders request a certain output from our CMDB, as part of our impact assessment we can ask the questions “how will we capture this?” and “how will this be maintained?” It may be that the request is unreasonable or unrealistic, and by involving our stakeholders on our CMDB journey and the decision-making process, it will align the business to a common goal in terms of its data and configuration management.
Next steps for the CMDB
The recommendations above provide a good starting point for your CMDB project. Once the initial scope of the data has been defined, the CMDB/CMS relationship understood, appropriate inputs and outputs selected, and some thought given to language and communication across the organisation, you will be in a good position to start work on the implementation itself.
The next stages might well include getting the right stakeholders in place, positioning the CMDB within the practices and processes of the broader IT and business environment, and identifying the potential obstacles during transition. The subject, no doubt, of another blog on this very important and challenging topic.