If you’ve ever worked with ServiceNow as an end user, developer, or administrator, you’ve probably come across the term CMDB (Configuration Management Database). A well-functioning ServiceNow CMDB is crucial for establishing efficient incident, problem, and change management processes in your organization. Without a strong CMDB in place, these processes might not be able to work effectively.
ServiceNow CMDB: Why is it important?
Let’s imagine a situation where a disruption occurs in a specific department's network, causing all workstations to be affected. In this case, an IT administrator could face significant challenges if the business maintains its device list in an Excel sheet, as manually identifying the routers and servers responsible for the issue is extremely time-consuming, especially if the document lacks sufficient details. As a result, your staff can only reach out to the 3rd party vendor for assistance, delaying the recovery time.
The situation would be different if the administrator has access to a CMDB. The database allows for prompt identification of the devices involved in the disruption, making it valuable for IT professionals. While setting up and maintaining a CMDB may require some effort, the benefits it brings, e.g. accelerated incident resolution and essential insights for making informed IT decisions, make the investment worthwhile and rewarding.
What is CMDB?
So, what exactly is CMDB? In simple terms, CMDB is a system that connects and integrates with your assets, giving you a full visibility of the IT infrastructure and configuration data. It allows organizations to effectively manage and improve IT service delivery as all software and hardware information is neatly stored and organised. Your team can easily reach details and records including servers, applications, routers, laptops, and desktops with an up-to-date CMDB.
Configuration Items
You can manage your CMDB through Configuration Management, an application of ServiceNow. It serves as a centralised database that stores information, known as Configuration Items (CI), about the different types of devices in your business with tables. A Configuration Item can represent:
Physical entity, such as a computer or router,
Logical entity, such as an instance of a database.
For instance, you can label a requisition service e.g. an Unix server with a corresponding configuration item record as "Unix Server CI." Within the record, you can further specify attributes and configurations associated with the server.
Attributes
Attributes are the pieces of information linked to a Configuration Item. They give additional details on the CI such as name, manufacturer, location and serial number, and are stored as columns in the CMDB tables.
In terms of a “Unix Server CI”, its attribute columns will include information e.g. name, manufacturer, operating system, company, model, ID, and RAM. You can refer to the above image for a more detailed look.
CI Relationship
Within a CMDB, a Configuration Item (CI) can establish relationships with another CI, demonstrating how the records are interconnected. The relationship data is then captured and stored in a separate table, where you can observe the mapping between parent and child CIs.
The "Related Items" section of a CI record form displays all the associated configuration items linked to the item. It also reveals the specific type of relationship they have, including but not limited to:
Runs on
Depends on
Connects to,
Used by
You can find more types of key relationships here.
For example, if an application is running on a Windows server, the CI record of the application will have a "runs on" relationship with the CI record of the Windows server.
Classes
In addition to relationships, Configuration Items are also categorised into different Classes. Each class corresponds to an individual table within the CMDB and contains CI records for devices or systems that fall under the same category. In essence, a class represents a group of CIs that share common attributes.
For example, as laptops, applications and servers all consist of their own set of details that are distinct from others. Hence, they can the different classes and will be labelled as "Computer", "Application" and "Server".
Each class table will contain fields or attributes specific to that class, along with some default CMDB fields. Additionally, you will find a "Class" field in CMDB tables that stores the value indicating the different types of classes present in the CMDB.
CMDB Data Schema Model
A CMDB Data Schema Model encompasses a series of connected tables that contain all assets and business services controlled by an organization. The model can be presented on a map, showcasing all connections among different CMDB records.
CMDB is indeed a vast topic and it's challenging to cover all aspects in one discussion. Don't worry though as we will delve into more advanced concepts in the upcoming blogs so that you'll have a comprehensive understanding of CMDB. Stay tuned and navigate CMDB with us!
Building a mature CMDB isn’t the easiest thing to do, but Unifii, as an independent ServiceNow partner can assist you in achieving your goals. Our experienced consultants have worked with clients in different industries and understand your needs better than anyone. No matter which stage you’re on in the CMDB journey, speak to us for a tailored strategic plan that can optimise your IT service delivery.