Are you storing information about your servers, laptops, and network equipment on spreadsheets or in a paper box? Maybe you already have an CMDB, but it has a lot of issues and no one trusts it.
How do you even begin to get to an "enterprise-class" CMDB? One that is powerful enough to manage the needs of your company and demands of users. This article will show you how and demonstrate some ideas make your journey a little bit easier.
What is Configuration Management (CMDB)?
A configuration management database (CMDB) is a repository that acts as a data warehouse for information technology (IT) organizations. Its contents are intended to hold a collection of IT assets that are commonly referred to as configuration items (CI), as well as descriptive relationships between such assets.
Configuration Items can be Servers, Laptops, Databases, Network equipment, Printers, Application, Website, etc. I usually think of a CMDB as the components that make up the company's network. However that isn't exactly true, it is a collection of IT assets. It can be a building, cloud resource, mobile phone, and even people sometimes. It depends on your company and what assets are important for you to capture.
Building the CMDB
Deciding Configuration Item Types
ServiceNow includes over 215 Configuration Item Types in the base system. These types are Servers, Laptops, Databases, Network equipment, Printers, Application, Website, etc.
Should you capture information for all these types? No.
Why is the answer no?
- Building overly large CMDB will make searches slow and maintenance unwieldy.
- Some of the CMDB information you may just not be important at the time
- You may not want to maintain certain CMDB information
Before you build your CMDB, plan out what data is important and capture that well. Capturing everything isn't necessarily wrong, but it usually introduces more issues than it helps.
CMDB Data Import and Discovery
There are various ways to import/create/populate the data in the CMDB. The worst ways to do this are importing spreadsheets and manual input. Using these methods usually mean your data will be out-of-date before you are done entering it.
I suggest getting CMDB data from a Discovery application such as ServiceNow Discovery, SCCM, Altiris, HP uCMDB, BMC Atrium etc. These applications scan the network and update CMDB information automatically insuring data is correct.
Which Discovery application to chose? Read this article: ServiceNow Discovery vs Integration with other Discovery Applications
If possible, use Discovery before importing your old data into a new ServiceNow system. Your old data is likely out of date, use the new information if you can.
Also consider using Service Mapping for additional ServiceNow discovery and mapping to Business Services.
Using the CMDB
One of the confusing parts of ServiceNow is why there is a CMDB and Asset Management. The reason why can be summed up in this statement:
Asset management and configuration management (CMDB) are related, but have different goals. Asset management focuses on the financial tracking of company property. Configuration management focuses on building and maintaining elements that create an available network of services.
Once you have that CMDB framework, use Asset Management to make it even more valuable. Put a cost to Configuration Items, make sure servers and laptops are deployed and retained properly.
What is the difference between an Asset and Configuration Item (CI)?
- Track the financial aspects of the item purchase, cost, and depreciation of the item.
- Contracts, Maintenance, Warranty, and Licensing tied to the item.
- Inventory tracking is expected to meet obligations.
- Document the status of the item, build, and decommission status.
- Record the technical attributes of the item
- Relationships to other Configuration Items
- Associated with an Incident, Problem, Change, or any task.
Build the CMDB using discovery, but pay with it using Asset Management. Something like that.
Service Catalog and Request Management
You can use the Service Catalog to have items for Server Builds, Server Decoms, and Server Updates. By using the workflow that Request Management offers, you can insure certain data (that isn't discovered) is updated in ServiceNow and servers are correctly managed.
Change Management helps organizations understand and work to minimize risks of changes to the IT environment. By having a robust CMDB, you can detect collisions and notify users of impending changes to company infrastructure.
Change Management is one of the most important applications in ServiceNow. Without it a company infrastructure changes are timebombs. It is not a question that a costly outage will occur, the question is when. Mitigate that risk by using Change Management. Change Management requires a CMDB to be truly effective.
Using a monitoring application, you can auto-create incidents against CIs in ServiceNow when an event occurs. There are many different monitoring applications you can use with ServiceNow. ServiceNow has Event Management, and you can use that or hook others up to ServiceNow with a plugin, Webservices, email, or other. Event Monitoring requires a CMDB for best usage.
Incident and Problem Management
Of course using CMDB data in Incident and Problem management is great. You can track an issue straight to the CI that caused it and find solutions. You can run reports to track CIs with the most issues or important CIs. You can run Incident and Problem without an CMDB, but the effectiveness is greatly diminished.
Running a CMDB unchecked is not a good idea. Especially if you have ServiceNow Discovery or various data import sources, you should run reports to determine if the CMDB is accurate.
I suggest setting periodic meetings to check CMDB data for accuracy and eliminate duplicates. One idea is to generate a monthly incident to make sure maintenance is completed.
Here is an article about how to build duplicate record reports: Duplicate Record Scripts
Here are some examples of other reports you can build (Some are included in the base system)
- Blank IP
- CIs Not Discovered
- Duplicate CI by IP Address
- Duplicate CI by Serial Number
- Not Classified
- Not Responding
- Connection Errors
Good CMDBs are unnoticed
If you think you will get a parade based on your efforts with the CMDB, you are mistaken. People typically only notice issues with a CMDB, but never realize how well constructed it might be. A good CMDB is transparent to the user and they take it for granted.
If you are receiving no complaints about your CMDB, this means you did a great job. :)