The legend of the Gordian knot was one of a supposedly unsolvable problem, a knot comprising several knots so tightly entangled it was impossible to see how they were tied. This is how some organisations see the creation of the database ITIL tells us is necessary to manage the many IT components they use to run their business, the CMDB.
The person who could untie this knot would be destined to become the ruler of Asia. Alexander the Great reasoned that it would make no difference how the knot was untied and so simply cut it in half. He later went on to conquer Asia, thus fulfilling the prophecy.
The creation of the CMDB has many pitfalls, some discussed in part 1 of this series. Here I will cover some of the steps you should consider as you set out to build your configuration database.
Building the foundation
- Start small, create a data model to support only the processes in your initial phase and focus on these.
The creation of a CMDB should be seen as an iterative exercise. You must create a foundation of trusted data before you can move forward. If you over extend yourself too early and don’t achieve a solid foundation, you will be building on sand.
- Identify the reference data sources (people, cost structures, locations, etc.) within the organisation and define a “contract” with the system owner for the data, quality and timeliness of provision.
High quality reference data is essential within an ITSM system and CMDB. For example, having timely updates of new starters is essential if you are running the on-boarding process or supporting users on their first day of employment. Getting internal service agreements in place to cover the day-to-day processes and changes is essential.
- Create a delegated ownership model for IT and application data with similar “contracts”
- Establish process alignment and ownership for each data field
- Have staff objectives tied to the quality of the data they own
CMDB data ownership is widespread, both within IT Infrastructure and beyond into application development, HR and Finance. It is essential that ownership and accountability are established and that robust processes are in place describing the processes associated with updating each key data field. A process that says “User shall update their data as appropriate” is not sufficient.
A good process will maintain data quality far better than management threats, although objectives tied to data quality goals help to keep employee focus.
An organisational culture of quality, supported by a tool that facilitates continual improvement should be the goal.
- Create measures to validate quality
Measurement of data quality is essential and needs to be considered from the very start. Considerations such as completeness, accuracy and timeliness are just some of the metrics that need to be considered. The subject of data quality will be covered in more detail in future blogs.
- Build processes that support data integrity
- Allow end-users to flag bad or missing data
- Use discovery to validate data created via process (such as closed loop changes management)
- Where data is mostly static and not discoverable, like Asset Ownership, use certification processes regularly to validate the integrity of the data. For example; “Are you still the owner of application X” or “Are you using software package Y”
Configuration management processes supporting the core processes can be used to validate data as part of the day-to-day. Creating small, lightweight processes that continually validate data and remediate are far better than waiting until the data is noticeably bad and performing a manual audit.
There are a variety of technical implementation considerations also, too many to mention here, so we will cover these in later articles.
Building a CMDB is much more than a technical challenge, it requires a foundation based on organisation alignment and cooperation. Committing to taking ownership of key data and agreeing to be accountable and to share this data is a crucial first step in the journey. Having tools to keep everyone honest, and facilitate a culture of quality, keeps the CMDB alive and adding value.
Author
David Osman
David has more than 25 years of IT experience working in investment banking, software houses and consultancy companies.
As TESM’s Chief Technology Officer, David is responsible for providing TESM’s thought leadership and innovation to the design and implementation of Service Management Solutions.
David’s experience includes building and running ServiceNow’s global application development organisation and implementing Service Management solutions for multiple large investment banks.
