CMDB in ServiceNow

Overview of CMDB:

If you have experience working in ServiceNow as an end user, developer, or administrator, you are likely familiar with the term CMDB (Configuration Management Database). Additionally, during your ServiceNow trainings(ITSM and ITIL ), you must have heard about the word CMDB. It is essential to have an effective CMDB in place for incident, problem, and change management processes to function efficiently within your organization. Without a robust CMDB, these processes may not operate effectively.

Why is CMDB important in any organization? 

Suppose there's a company named "ABC". Now imagine a situation where a disruption occurs in a specific department's network, affecting all workstations. In such a scenario, an IT administrator would face challenges in manually identifying the routers and servers responsible for the issue as ABC maintains their device list in an Excel sheet with inadequate details. Hence, the issue will be solved by reaching out to the vendor. However, if the administrator has access to a CMDB, they can promptly identify the routers, servers, and other relevant infrastructure involved.

In the above example the issue was resolved, still this cannot be considered as an effective resolution. So, it becomes evident that a CMDB holds immense value for IT professionals. While setting up and maintaining a CMDB may require some effort, its ability to accelerate incident resolution, and provide crucial insights for informed IT decision-making means that the investment pays off quickly.

So, what exactly is CMDB? In essence, CMDB is a vital system that allows organizations to effectively manage and improve IT service delivery. By understanding the systems used within the IT environment and having access to their configurations, organizations can gain valuable insights into their IT infrastructure. 

CMDB (Configuration Management Database):

It is a repository that stores information about the software and hardware assets or devices within an organization, such as servers, applications, routers, laptops, and desktops. Keeping the CMDB up-to-date is crucial for effectively delivering IT services. When implemented and maintained well, a CMDB provides organizations with complete visibility into their enterprise infrastructure, offering reliable configuration data for physical and virtual servers, computers, routers, and more.

ServiceNow have an application called Configuration Management to manage the CMDB. It serves as a centralized repository database with different tables that store information about various types of devices. The CMDB consists of entities known as configuration items.

In the ServiceNow CMDB, you can find a list of CI records that are stored in a table. A configuration item can represent:

Physical entity, such as a computer or router, 

Logical entity, such as an instance of a database.


For example, a requisition service like a Unix Server can be requested, and its corresponding configuration item record would be labeled as "Unix Server CI." An example of a specific CI record is "Unix 200," which displays the attributes and other configurations associated with that server.

Attributes: 

Attributes are the pieces of information associated with a configuration item (CI) that provide details about the CI, such as its name, manufacturer, location, serial number, and more. These attributes are stored as columns in the ServiceNow CMDB tables and can be displayed on the form. For example, the columns including, name, manufacturer, operating system, company, model, ID, and RAM, are attributes of the Unix server CI, and their corresponding values pertain to that specific server.

To access the CMDB application, you can navigate to the application navigator in ServiceNow and search for "Configuration." This will lead you to the Configuration application. Within this application, you will find different modules that you can access for different types of CMDB tables. 

CI Relationship:

Within the CMDB, a configuration item (CI) record can establish relationships with other CI records. ServiceNow maintains the relationship between different CI records in a separate table. A CI relationship stores information about how different CI records are connected to one another. Let's consider the example where a Unix server is utilized by a NeedIT application. This implies that the organization has a NeedIT application that relies on a Unix server to carry out transactions.

The CI relationship table is dedicated to storing information about the relationships between different CI records. In the list of CI relationship records, you can observe the mapping between parent and child configuration items and their specific types of relationships. 

The "Related Items" section of a CI record form displays all the associated configuration items linked to the current CI. It reveals which CI records are related to the current one and the specific type of relationship they have.



In the CMDB, there are separate CI records for the application, server, and database. Each of these devices has its own CI record. However, the relationship between the application, server, and database can also be stored in the CI relationship table.

CI Relationship Type:

The categorization of the relationship between two CI records is referred to as the relationship type or CI relationship type. It helps determine the nature of the relationship between the CI records. Relationship types can include:

"runs on," "depends on," "connects to," "used by," and more. 

For example, if an application is running on a Windows server, the CI record of the application will have a "runs on" relationship type with the CI record of the Windows server.

In the "Related Items" section of a CI record form, you can also view the relationship type between different CI records. It provides visibility into the type of relationship associated with various CI records.

Key Relationships: 

https://docs.servicenow.com/bundle/rome-servicenow-platform/page/product/configuration-management/concept/c_CIRelationships.html

Class:

In the CMDB, different types of devices or systems are represented by various configuration items (CIs). However, it's essential to identify which CI record corresponds to a Unix server, an application server, or an application. To accomplish this, configuration items are organized into different categories known as 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 category or group of CIs that share common attributes.

For example, if we have laptops, applications, and servers, each of these device types will have its own set of details that are distinct from the other device types. In this case, the class of the CI records would be

"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:

The configuration management database (CMDB) data schema model consists of a series of interconnected tables that store information about the assets, business services, and their configurations that are managed by an organization. These tables establish relationships between different CMDB records, including parent-child relationships.


For further understanding Click here.

https://www.unifii.co.uk/insights-and-resources/blogs/back-to-the-basics-servicenow-cmdb-in-a-nutshell

Previous Post Next Post