While working to build the value statement for the ServiceNow Configuration Management Database (CMDB) and demonstrate its breadth of information we decided to try and provide an easy-to-understand picture, something close to a relational database model turned out to be just the tool needed.

If we look at the first few levels of the CMDB tables as a base for our data model, we can turn it on its side and it does in fact appear to be mountain-shaped.

ServiceNow depiction of the first few levels of the CMDB table


As we dive deeper into any given table, ServiceNow provides a wealth of information on each and every table in the CMDB: from data elements and keys to relationships and hierarchies. It quickly becomes an overwhelming amount of data with no clear way to create a path forward with understandable information.

So how do we reduce this mountain of information and make conquerable, usable molehills?
This is the process CapTech performed at a Fortune 500 client that is easily extendable and accomplishes this in a fairly straight forward manor; a key component is the extensive use of layers and coloring within the lines:
1. Capture the core CMDB tables with their data elements


2. Now we can define their inheritance from the top down


3. Group each of the tables in layers that define the major IT function areas:

  • Applications
  • Database
  • Facility Hardware
  • Personal Computing and Mobile
  • Network
  • Server
  • Storage
  • Networking

4. We add indicators for configuration items updated by discovery
5. Identification of data that has a system of record upstream of the CMDB.


6. We then can tie in the cross functional (Foreign key) relationships
7. Reference tables can begin to tie these together in a very fundamental way


8. Next up, we extend the tables with the Asset and Extended CMDB data, repeating the top-down and bottom-up approach and exercise we just completed
9. We are now ready to tie the Extended CMDB, Asset and CMDB data together with another level of relationships and dependencies


Ok, so maybe it might not be a molehill, perhaps more like an anthill in its complexity. We can create simplicity in thought and deed through story development and preparing appropriately shaded lenses that provide the perspective at any given time. The model from these perspectives provides a needed clarity to understand everything from a single table, extended CMDB, Asset integration, and Discovery. However, these aspects can be quite deep too. Perhaps this is more of an ant hill in the depth and breadth we have.

The model makes an excellent reference tool to gain a visually intuitive understanding of the data and its relationships that go along with the story being told.
What we ultimately end up with:

  • An atomic level blueprint to support the first 18 months of CMDB, extended CMDB and Asset Management implementations
  • A functional tool to support the building out of the business service relationships
  • A bridge from the high level conceptual model of the CMDB to the Physical Model and classes available from ServiceNow

Please remember to keep this up to date as your CMDB expands; neglect is death to a model.