Configuration Best Practices

Before beginning the installation and configuration steps, review the following best practice guidelines.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 ServiceNow CMDB. This is what our customers will typically hear from ServiceNow or their partners and from documentation.

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.

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.

Implement ServiceNow Discovery: If you are populating your CMDB automatically, consider using ServiceNow Discovery or Service Mapping for automated, agentless discovery of CIs and their relationships.

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.

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.

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.

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.

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.

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.

Multi-Source ServiceNow “IntegrationHUB” Best Practice

Here we’re looking at general “best practice” for how to manage multi-source data going into the CMDB through ServiceNow’s “IntegrationHUB.” This guidance, again, is not specific to the Flexera One integration.

Source Identification: Clearly label the source of each CI so that you can track back issues and updates to the original source system. This can be helpful for auditing and data quality.

Normalization Rules: Leverage IRE's normalization capabilities to ensure that the incoming data adheres to a standardized format, making it easier to manage and use.

Deduplication: Use the Identification Rules within IRE to ensure that incoming CIs are not duplicates of existing records. Configure these rules to take multiple sources into account.

Conditional Transform Maps: Make use of ServiceNow's robust transform maps to conditionally process incoming data. For example, you might want to transform incoming data differently based on its source or the type of CI.

Prioritization of Sources: In a multi-source environment, conflicts can arise when the same CI is discovered or managed by multiple tools. Use IRE to establish source precedence rules.

Reconciliation Policies: Implement reconciliation policies in IRE that determine how conflicts between data from different sources are resolved.

Batch Handling: When integrating large volumes of data, use batch processing to minimize performance impact. Set up IntegrationHUB to collect and push data in batches rather than in real-time, if acceptable.

Error Handling: Implement robust error-handling and logging mechanisms to capture and report errors in the integration flows. Ensure that these are monitored regularly for prompt resolution.

Validation and Testing: Before pushing data from a new source into your CMDB, validate it in a test environment. Make sure the IntegrationHUB flows and transform maps are thoroughly tested with representative data sets.

A Note regarding “Service Graph” and Compatibility

“Service Graph Connector” (SGC) is essentially a moniker for an integration that meets certain explicit governance, uses IntegrationHUB and its tools, and has gone through a more stringent validation process than a typical application in ServiceNow’s store. On top of meeting those qualifications, it also has to pass a business review to determine if ServiceNow wants to allow that integration to be a part of the “Service Graph” library/partnership. There is little unique about a SGC integration, and other non-SGC integrations can still meet all the same governance and validation levels as an SGC integration. The Flexera One integration, in that way, is compatible with SGC and is capable of plugging into an IntegrationHUB environment along side IntegrationHUB “Spokes” or SGCs and can be managed in the same way because it uses the same key free components from IntegrationHUB, including IRE (Identification and Reconciliation Engine), Robust Transform Maps, uses “Cleanse” operations from “Integration Commons,” writes to the “Source” tables in the same was as required of those integrations, and sticks to an out-of-the-box approach for tables and columns.