Our team was helping a Fortune 500 client expand its ServiceNow's configuration management database (CMDB). Some basic configuration item (CI) data was populated; for example, servers, databases and software. In CMDB, up-to-date and accurate configuration data provides a single system of record for the organization's IT department. It also helps the organization identify the exact number of assets in the IT environment. Our client understood the importance of configuration data and wanted to expand the CMDB to capture more data for other CI classes such as network gear, printers, scanners and personal computers.
To expand the CMDB efficiently, we needed a complete picture of the data structure. The lack of a complete picture hampered our requirement discussions with business users as well. ServiceNow provides a lot of out-of-the-box tables in the CMDB for all kinds of CI classes. Before capturing new data, we had to manually search the CMDB to find an out-of-the-box table using the name of the CIs we were trying to capture. For example, to store data related to network components in the environment, we searched for "network." This method of finding suitable out-of-the-box tables was both cumbersome and inefficient. It was cumbersome when we were trying to capture data for multiple tables. Inefficient because we weren't certain which table to pick as our search returned multiple results and relationship among all the tables wasn't clear.
Another challenge we faced involved identifying and rectifying data redundancies in the CMDB instance. A group of consultants who had worked on the project previously had created custom tables under the computer table (cmdb_ci_computer) instead of using existing out-of-the box tables to capture desktop and laptop data. Without a picture of the CMDB data structure, it was difficult to determine whether custom tables could be eliminated and data can be transferred to out-of-the-box tables.
To get a better understanding of the CMDB data structure and how tables relate to each other, we created a CMDB data model. It was a long and challenging process because there are hundreds of tables in the environment and we had to analyze all of them. After analyzing a few, we realized that most of the tables extend from the configuration item (cmdb_ci) table. So we started our data model with this table and began looking at the child tables followed by the children of these child tables.
In our effort to expand the CMDB, we met with different stakeholders and used our CMDB data model to elicit their requirements. We began by explaining what tables ServiceNow provides out of the box. We then identified different types of CIs the teams managed and mapped them to out-of-the-box tables. This helped the business users to think about different ways they can manage their data in the tool. For example, one team was managing the network devices along with the name of the racks on which these devices sit. There were several other attributes related to a rack that they were not tracking because the attributes were too complicated to track in the Excel sheet they historically maintained. After seeing various out-of-the-box "network gear" tables and a specific table for rack information, in addition to "network gear" tables, the team wanted to utilize the "racks" table, track additional information for all racks, and relate each rack CI to specific network gear CIs.
To eliminate data redundancies, we used the data model and found the personal computer (cmdb_ci_pc_hardware) table. This is an out-of-the-box table that extends to desktop PC (cmdb_ci_desktop_pc) and laptop PC (cmdb_ci_laptop_pc) tables. Because attributes for both desktop and laptop were similar, we decided to keep data for both CIs under the personal computer table differentiated by a type (desktop/laptop) field.
The configuration item (cmdb_ci) table captures basic attributes for all configuration Items. The attributes available in this table can be used across all child tables. Before creating a new field, it is important to check the parent tables as well as the CI table to ensure the field is not provided out of the box.
There will be scenarios in which an out-of-the-box field is not available in the CMDB for a particular requirement. If the field is needed for a specific table, I would create it under that table. On the other hand, if the field is going to be needed by multiple tables, I would create it in the parent or even in the CI table so that the field is not duplicated across multiple tables.
Whether your organization is just starting with the CMDB or is working toward expanding the CMDB, understanding the CMDB data structure is very important to successfully organizing assets in a logical manner. Whatever your CMDB needs may be, initial efforts to create a data model can help:
Your business analysts in eliciting better requirements from the users by showing what ServiceNow offers out of the box. The data model can help them explain what type of data can be captured and how it can relate to other entities in the CMDB
Your implementation team in making good design decisions by eliminating the need for custom tables and fields
Your stakeholders in managing CI inventories effectively and accurately by understanding how CIs relate to each other and identifying other pieces of data that can be tracked in the tool
About the Author
Piyush Dagar is a consultant in our Richmond, VA office. He is a Certified Scrum Master (CSM) and has over 5 years of experience as a business system analyst specializing in the areas of business intelligence and analytics.