What is a CMDB Data Dictionary?
A CMDB Data Dictionary is an unsung hero of Configuration Management. In its most basic form, it is a catalogue of the Tables, Attributes and purposes of each Class and Attribute in the CMDB. While this might not seem of particular import compared to other activities in a comprehensive Configuration plan – I like to think of it as being functionally identical to keeping your tools in fancy foam dividers in your tool drawers. If you are a Land Rover owner, or a cyclist, or keen carpenter… you likely know the value already of having a tidy tool chest.
If you head to your workshop and immediately have to root through your drawers to find a tool it adds time and difficulty to the process (which is not good, given every thirty minute job is a single stripped bolt away from being a three day ordeal). Why is it, then, that we come to work in the IT universe and leave our common sense in the workshop? The premise is identical for your CMDB. If you need to root through the drawers to identify the purpose of an attribute before achieving benefit you are introducing inefficiency to the process – and thus enters the CMDB Data Dictionary.
While the reasoning “because my tool chest is tidy and I want my work to reflect that” might suffice for those of us at the implementing level, for those holding the purse strings, slightly more justification is often needed. While I cannot articulate the benefit to your business, I will outline some of the general benefits and you can choose (or not, as you desire) to make your case accordingly.
Build Value, not Perfection
Whether it was Voltaire or Winston Churchill who said it (or neither), the widely attributed “perfection is the enemy of good” quote rings true. While it is key not to leverage that as opportunity to lazily implement something which doesn’t meet your needs – it aptly captures an intent which is focused on getting to benefit as opposed to being involved in process.
How we get to value will depend on a great many things. Most notable, of course, are factors such as time, process maturity and tools or the information available to ourselves. A mature organisation with myriad resources at its’ disposal will likely have a different outcome than a smaller one, which may operate more lean as regards people – but with much greater agility with regard to things such as leveraging AI to produce outcomes.
What follows is an explanation of the key components of a Data Dictionary as well as some examples of how to produce them. The hope is that you can then take your understanding of these components and apply it to your own operating environment. So, are you sitting comfortably? Then let’s begin…
First, what are we dealing with?
The first step toward building a CMDB Data Dictionary is to understand what you have. Think of this step as emptying your tools onto your workshop floor. Yes, it’s likely going to be messy – but progress cannot be made if this step is omitted.
There are many differing approaches to identifying the classes and attributes in use across your CMDB. For example, you might:
- Use an MCP Server and Claude to interrogate your CMDB, prompting it to produce a consolidated list of CMDB Classes (along with table names) with records present, as well as the attributes in use across those.*
- Running a fix/background script in a pre-production instance to produce a consolidated list of classes / table names and attributes in scope.
- Exporting principal classes to Excel and consolidating using pivot tables.
The key point here is not to stress about how exciting you can make this step – but rather to have a consolidated list of classes and attributes actually in existence.
Second, what is it we’re meant to have?
This is where we tie in your CMDB Data Dictionary to your Configuration Management Plan. There’s what you have, what you’re supposed to have… and potentially what you have which you should not. At this point in the process, it is appropriate to identify which of the following three categories a Class or Attribute sits within so you can handle it accordingly.
|
It’s there, and it should be (good) |
Record in your Dictionary. Include the purpose, disposition and any other information you need to support its’ use. |
|
It’s there, and it shouldn’t be (bad) |
Record in your Technical Debt log. Raise Demand/Story to refactor/consolidate/remove. Handle through your CMDB Architecture process. |
|
It’s not there, and it should be (missing) |
Raise Demand/Story to implement. Capture requirements from class owners as new requirement. Handle through your CMDB Architecture process. Once implemented, record in dictionary. |
The key point here is to identify the scope and deltas and to push the work to remediate the differences through the existing processes. CMDBs are often considered abstract from reality or process, but that is the single most frequent cause of failure in my experience. Do not throw additional resources into making decisions outside of process – that is how you likely got into this situation. Put the work to close the gap through the correct process. If you need to go faster, speed that process up. Do not side-step it – “if you don’t have time to do it properly now, when will you?”
Building the Data Dictionary
As previously stated, this is not a how-to. This is a primer, from which you can make your choices as they are appropriate for both your needs and your organisation. An introduction to two options follow. I’ve put them into a top-trumps style approach because I find it helps easily surface good/bad. Of course, you can use Confluence, Microsoft Excel – anything which works for your Organisation as long as it is and remains authoritative and is properly embedded into process.
CI Class Manager
- Documentation is -> here.
- Accessible for -> ITIL, CMDB roles.
- Setup Required -> None.
- Can take notes or comments -> No (which is no help when you need to categorise or describe the purpose of an attribute).
- Special Powers -> Covers every CI class and attribute with IRE, inheritance of attributes and you can configure CMDB Health metrics too – if it’s in the CMDB, it’s visible in CI Class Manager.
- Biggest drawback -> Because it covers every CI class and attribute but doesn’t allow for comments, it can be hard to know what you’re looking for or at.
Data Model Navigator
- Documentation is -> here.
- Accessible for -> The application shipped roles – read/write.
- Setup Required -> Yes. Configure a Context, Table, Field record for each attribute in use.
- Can take notes or comments -> Yes (which is the key thing missing from CI Class Manager).
- Special Powers -> Because you have to configure it, you only add what is in scope. And then you can describe its’ purpose – and NowAssist can use the model to understand the CMDB.
- Biggest drawback -> You have to configure it, so there’s an up front investment. When you have, though, it’ll look something like this:
Using the Dictionary
Return on investment time! Clearly, having put in a “surge effort” to realign the CMDB with business outcomes, it’s good to get some value from the Data Dictionary. Doing so with a Data Dictionary is no different to a normal one – when you have a question, you refer to it. Some examples include:
|
Why? |
Who? |
When? |
|
A demand to implement a new Attribute, Class or Capability in the CMDB needs to be assessed for validity. |
Architect, Business Analyst, Product Owner, Platform Owner |
During/as part of Story definition and Architecture Review Board. |
|
A request comes in to the Configuration Management team to provide a report, and they are not sure how to run it. |
Configuration Management |
As part of fulfillment of the request. |
|
Auditors require proof of certain attributes against key Infrastructure and Application items as part of regulatory checks. |
Configuration Management team, Auditors/Compliance. |
Before/during compliance or regulatory audits. |
Conclusion
Hopefully having read this, you understand some of the benefits of a CMDB Data Dictionary. Remember – whatever your organisation needs, focus on meeting those in as simple a manner as you can. Progress and utility should be sought over perfection. Integrate the Data Dictionary into your existing processes, involve people, leverage it to better integrate your CMDB into business needs. If you do all those things, you won't need to tidy up the workshop again!
Footnotes
*This has potential to be quite expensive. I tried it using Claude Opus 4.8 via Terminal. Time to complete the activity (including analysis of 94 CI classes and write to the Data Model tables) was ~32 minutes, ~3.3m tokens, meaning the job cost ~$4.54 as displayed below. I imagine that running an export or providing the data to Claude rather than having it fetch would be simpler / cheaper, but I wanted to test the full lifecycle of the approach. It is important to note that the data in my instance is demo data only. An operational environment with ~millions of Cis would likely not be a sensible place to attempt this (from both a cost or regulatory perspective)!
