CMDB Best Practice
This section includes two lists that provide best practice guidance for CMDBs, generally, and for ServiceNow CMDBs, more specifically, as well as some additional information about deleting CIs, staleness processes, and CMDBs.
General CMDB Best Practice
This is general guidance about how CMDB implementations and governance should be approached, in general, not directly in relation to the Flexera One integration or even ServiceNow.
|
1.
|
Agree on Your Goals and Objectives for the CMDB: This is crucial. A CMDB that doesn't align with business objectives can become an expensive, underutilized asset. |
|
2.
|
Architect Your Data to Support Your Objectives: Data architecture should facilitate the business goals. It should also be scalable and extensible to accommodate future needs. |
|
3.
|
Have Clear Roles and Responsibilities for your CI Owners: This can't be stressed enough. Clear ownership ensures data quality, timely updates, and proper governance. |
|
4.
|
Identify the Sources of Data Available for Populating and Managing CI Records: Knowing where your data comes from is key to managing data quality and integrity. |
|
5.
|
Identify What Data You Will Manage and What Data is Referential: This helps in data governance and data quality efforts. It also aids in defining what should be in the CMDB versus what can reside in other databases but be referenced when needed. |
|
6.
|
Enable the People Responsible for a CI the Ability to Control Their Data: Empowering CI owners ensures they are more engaged in maintaining data quality, which can often be a major pain point. |
|
7.
|
Don’t Populate Data Without a Plan to Manage It: This is a common mistake. Populating data without a plan often results in outdated or incorrect data, defeating the purpose of a CMDB. |
|
8.
|
Don’t Strive for Perfection: This is realistic and pragmatic. It's better to start with a “good enough” approach and then iterate for improvements. |
|
9.
|
Deliver to the Needs of the Processes the CMDB Supports: The CMDB is not an island; it's meant to be a living, breathing entity that supports ITIL processes like Incident, Problem, and Change Management. |
|
10.
|
Clarify the Lifecycle Status Values of a CI: This is essential for accurate reporting and for understanding the CI’s current state, whether it's in procurement, active, in maintenance, or retired. |
ServiceNow CMDB Best Practice
This is meant to be like the above, but more specific towards the ServiceNow CMDB. This is what our customers will typically hear from ServiceNow or their partners and from documentation.
|
1.
|
Utilize CMDB Health Dashboards: ServiceNow provides CMDB Health Dashboards that offer key metrics like completeness, correctness, and compliance. Make use of these dashboards to continuously monitor the state of your CMDB. |
|
2.
|
Leverage Identification and Reconciliation Engine (IRE): ServiceNow's IRE can help you with CI identification, normalization, and deduplication. Set up robust identification and reconciliation rules to ensure data quality. |
|
3.
|
Implement Discovery Tools: Leveraging automated discovery tools—such as SCCM, Flexera Agents, ServiceNow Discovery, and Intune—is essential to keeping your CI data and CI relationships current. In most cases, manual efforts will not be enough to keep your CMDB data accurate and current regardless of how good your manual processes are. |
|
4.
|
Apply Access Controls: ServiceNow's Access Control Rules provide granular control over who can read, write, and delete CIs. Use this feature to implement least-privilege access to your CMDB. This helps protect the data quality of your CMDB as well as keeping potentially sensitive CI data from being widely visible. |
|
5.
|
Integrate with ITSM Modules: Utilize built-in integration with ITSM modules like Incident, Problem, and Change Management to ensure your CIs are automatically updated based on these processes. |
|
6.
|
Customize Carefully: ServiceNow allows for extensive customization. However, limit this as much as possible to ensure that you can easily upgrade to new versions without breaking your CMDB. |
|
7.
|
Utilize CI Class Manager: Use the built-in CI Class Manager to effectively manage the CI classes and their hierarchies, making it easier to query and manage your data. |
|
8.
|
Scheduled Jobs for Data Maintenance: Use ServiceNow’s scheduled jobs for data maintenance tasks like deleting orphan CIs, validating data against rules (“Staleness” for example), and other routine tasks. |
|
9.
|
Audit and History Logging: Enable audit and history logging for critical CI classes to ensure you can track changes over time for compliance and debugging purposes. |
A Note on Deleting CIs
While it is generally considered acceptable to delete “orphans” (such as a network adapter with no associated computers), it is considered a “bad practice” to delete CIs. In general, deletion should be a last resort, considered only after all other avenues have been explored. If the amount of stale or inactive data is creating an actual problem, the suggested approach would be to implement a “archiving” method.
There are several reasons for this, such as legal or compliance reasons, (especially involving hardware CIs) but the most obvious is typically the impact deleting a record can have on other historic records such as changes, incidents, requests and more.
If it is decided to implement an “archiving” method, it should be warned this is not a simple solution, however it is usually worth doing. A careful impact analysis needs to be done to understand the relationships and processes those CIs may be involved in to make sure no historic data is lost but is instead maintained through the archiving process.
A Note on Staleness Processes In ServiceNow
One of the primary methods in ServiceNow for managing “discovered” hardware and software is the concept of “staleness.” ServiceNow has several “metrics” around CMDB health. Two of the primary key metrics revolve around “orphans” and “staleness.” Staleness refers to how long it has been since a “discovery source” has last seen a particular CI. This concept is used to determine if a CI should be automatically considered “Inactive” as well as if a “software installation” should be considered no longer installed on a CI. A scheduled job will typically run to “clean up” stale records but what that clean-up entails will vary to a degree according to customer needs. There is also a business rule that will “clean up” software installations should the hardware CI its associated with get marked as “retired.”
More About CMDBs
The CMDB is in many ways, the heart of automation. Most business processes touch on either CIs, hardware or software in some way. As such, a fully realized and accurate CMDB is one of the keys to getting the most ROI out of ServiceNow but it cannot be done with half measures and without appropriate governance and support or it will turn into a money/time sink instead.
The processes that involve CIs or Assets need to be fully understood. What data is the organization interacting with? How are they using that data? And how should that data be kept up to date? Nothing should go into the CMDB without a solid process to keep it accurate. Either through discovery, or when the CI/Asset is touched, part of the process needs to be feeding that update information back into the CMDB. Roles need to be identified and staffing needs to have the bandwidth to perform their tasks.
The approach to the CMDB needs to be strategic not tactical. By that I mean the big picture needs to be understood and designed around, not just a piece of it. Only the configuration management team should ever be creating CIs manually.