IT today is more than ever Information technology.
While the creation, manipulation and use of data is nothing new, today it has taken on new meaning as more and more systems produce and use data from Kettles to Compute in the cloud.
Out-of-the-box ServiceNow, expects data to be present to support all key processes, facilitating efficiency, automation and world-class customer experience. The data can take many forms: information about employees, cloud resources, computer hardware and software, applications, business services and the many attributes required to describe a modern business.
ServiceNow recognises the need for data in calling itself “the system of record” moving more recently to “the system of action”. Both are predicated on the need for a high-quality data foundation.
The challenge is that the CMDB, the database used to store and manage much of this information, still remains an aspiration for many organisations. Where the CMDB exists, data is often incomplete, inaccurate and out of date.
Why is building a CMDB hard?
- The data in a CMDB comes from every part of an organisation and so getting the necessary information needs alignment and possibly investment at a company level.
- Most large organisations still have a heterogeneous infrastructure with a lot of moving parts. The “data” goalposts will be constantly moving.
- There’s a lot of data out there, and the volume is increasing every day.
What are the common mistakes associated with building and running a CMDB?
- Leaving the CMDB too late in an ITSM project
- Without data from the CMDB your ITSM platform becomes a basic ticketing system. All the process efficiency, automation, reporting and data driven features will not be available, or at best, severely limited. The Service Desk will bear the brunt of the effort if this is not in place.
- You only get one chance at a first impression and leading a project without a CMDB will create a highly manual implementation and be the cause of a poor user experience.
- If a CMDB is established after an initial roll-out, the implementation will need to be retrofitted to make use of the data, which will mean extra cost and disruption to users.
- High expectations and over reliance on the capabilities of discovery tools
- There is no doubt that discovery tools can provide useful information. They are however reliant on the environment that they are scanning providing consistent and understandable data. This is not always the case.
- Time and effort is required to set up and manage the various data domains, normalising data, managing duplicates and keeping up with the ever-changing enterprise environment.
- Do not expect to be able to populate your CMDB using discovery alone, the most successful configuration processes use a combination of data created via process, supported by and validated with discovered data.
- Not establishing key sponsorship at a high enough level of an organisation
- The data that populates a CMDB spans the organisation and so it is important to have sponsors senior enough to prioritise work relating to the CMDB in that context.
- A CMDB requires ownership to facilitate data stewardship (configuration management) and to ensure it stays up to date with changes within the enterprise in which it lives.
- The process of managing the CMDB is also the process of managing the outcome of change in an organisation. As well as creating, interpreting and publishing data quality reports, the config manager must be aware of the overall IT strategy and how it is changing so that the CMDB can keep in lock step with the enterprise.
- Without an owner ensuring the database stays fit for purpose the CMDB will stagnate.
These are a few of the common challenges that can hamper the creation of a configuration database. The task of starting such a project can seem daunting, just like the Gordian knot of legend. In the story, Alexander the Great, figured that rather than untying the knot, it would be easier to simply cut it in half. With configuration management, there are similar techniques a company can use to simplify and speed the creation of a CMDB.
Watch out for my next blog where I will start to discuss some of the “tips and tricks” to creating a robust configuration database.
Other posts in this series: