ServiceNow Discovery Optimisation

What Discovery Optimisation Addresses

Discovery automatically identifies infrastructure assets by scanning networks and cloud environments. Over time, discovery configuration often becomes outdated or inefficient. Optimisation reviews discovery probes, adjusts scanning parameters, removes obsolete discovery patterns, and improves accuracy of discovered assets.

Optimisation aims to reduce unnecessary scanning that consumes network bandwidth and infrastructure resources, improve the accuracy of discovered data to reduce manual corrections, and ensure discovered data flows correctly into the CMDB.

Discovery Probe Performance and Tuning

Discovery probes scan networks and systems to identify assets. Over-aggressive probing can consume network bandwidth and trigger security alerts. Tuning adjusts scanning frequency and scope so discovery captures necessary data while minimising overhead.

Some probes are no longer needed because systems they discover have been decommissioned. Removing obsolete probes reduces unnecessary scanning and makes discovery configuration easier to maintain.

Pattern Management and Accuracy

Discovery patterns match discovered data to discovery model (the list of asset types Discovery knows about). Patterns that are too broad might misidentify systems; patterns that are too narrow might miss assets. Review of patterns improves matching accuracy and reduces manual corrections.

Discovery data quality is assessed: are discovered assets correctly typed, are relationships correctly identified, and are obsolete assets being removed. If discovery accuracy is low, discovered data clutters the CMDB and makes incident impact analysis unreliable.

CMDB Integration and Data Reconciliation

Discovered data flows into the CMDB, enriching the inventory. Optimisation reviews how discovered data is mapped to CMDB attributes. If mappings are wrong, discovered data doesn’t enrich CMDB and may create duplicates.

Reconciliation identifies duplicates in the CMDB where discovery has created multiple records for the same asset. Deduplication merges duplicate records and cleans up the CMDB.

Cloud Environment Discovery

Cloud discovery requires cloud provider credentials and API integrations. As cloud environments grow, discovery scope expands. Optimisation ensures cloud discovery is configured efficiently and isn’t discovering resources that have been decommissioned.

Monitoring and Alerting

Discovery health dashboards show how many assets were discovered in recent runs, error rates, and how long discovery is taking. Alerts notify administrators if discovery fails or takes significantly longer than expected.

Oblytech’s Discovery Optimisation Services

We review discovery configuration and identify probes that are obsolete or over-aggressive. We tune scanning parameters to balance coverage and efficiency. We assess CMDB integration and recommend improvements to data flow. Implementation includes pattern refinement, deduplication, and validation that optimised discovery produces accurate asset inventory.

Cloud Discovery and Multi-Environment Support

Modern environments include on-premises, cloud (AWS, Azure, GCP), and hybrid resources. Discovery must work across all environments. Cloud provider integrations pull resource data directly from cloud APIs. Discovery configuration should prioritise high-value assets in each environment.

Handling Discovery Conflicts and Duplicates

When multiple discovery sources run, duplicates may be created. Deduplication logic identifies when different sources have discovered the same asset. Manual and automated deduplication processes reconcile duplicates into single CMDB records.

Performance Tuning and Optimization

Discovery performance should be monitored to ensure discovery runs complete within acceptable timeframes. As environments grow, discovery tuning ensures probes are efficient. Database optimisation and resource allocation keep discovery responsive.

Lifecycle Management and Retirement

Discovery should identify assets nearing end-of-life and flag them for retirement planning. Assets that are no longer discovered in multiple consecutive discovery runs should be reviewed for decommissioning. Systematic retirement keeps the CMDB clean.

Asset Naming and Identification Conventions

Discovered assets should follow consistent naming conventions so they can be easily identified and matched across systems. Naming conventions help prevent duplicates when multiple discovery sources report the same asset. Standardised naming makes CMDB data more searchable and interpretable.

Continuous Optimisation and Process Improvement

Discovery optimisation is not a one-time activity but an ongoing process. Quarterly reviews of discovery performance, accuracy, and resource consumption identify further optimisation opportunities. As the technology environment changes, discovery configuration should evolve to stay current with the environment.

Governance and Change Control for Discovery

Changes to discovery configuration should be tested before deployment. Changes might affect what assets are discovered and how they’re classified in the CMDB. Testing ensures changes have intended effects without unintended consequences. Governance ensures discovery remains accurate as configuration evolves.

Collaboration Between Discovery and CMDB Teams

Discovery teams and CMDB teams must coordinate. Discovery provides data; CMDB team determines accuracy and integration. Regular communication ensures discovered data is trusted and used effectively. Collaboration meetings can address data quality issues and identify improvements.

Ranking changes by how hard they are to reverse

Discovery tuning goes wrong when a team changes the most powerful setting first. Removing a pattern, narrowing a scan range or changing an identification rule can each remove data that the business relies on, and some of those removals are hard to undo because the CMDB has already been reconciled against the new picture. A safer approach is to rank the available changes by reversibility before choosing any of them. Schedule changes and scan ranges can usually be reverted in the next cycle. Pattern changes affect what gets classified, so their effect appears in records over several cycles. Identification and reconciliation rule changes are the hardest to reverse, because they decide which records are merged and which are kept apart.

Starting with the reversible changes also gives the team evidence before it touches anything that is difficult to undo. A schedule adjustment that cuts run time without losing items is a useful signal that the scope was larger than it needed to be.

Levers, what they change, and what they risk

Lever	What changes	Reversibility	Main risk
Run schedule for a target class	How often a class is scanned and at what hour	Reverted in the next cycle	Stale data for a class that changes quickly
Scan range or cloud scope	Which targets are included at all	Re-added in the next cycle, but records for removed targets may age out	Items disappear from reporting while still running
Probe retirement	Which probes run at all	Requires reinstalling and reconfiguring a probe	Silent loss of a zone that nobody has checked since
Pattern enablement or disablement	Which software and hardware types are classified	Takes effect over several cycles	A disabled pattern hides a product that a service depends on
Identification or reconciliation rule	Which records are treated as the same item	Hard to reverse once records have merged	Merging distinct items and cutting their relationships

Tuning sequence for an estate that has grown untidily

An estate that has been scanned for several years usually carries leftovers from earlier decisions: probes for sites that closed, patterns for products that were retired, and cloud accounts whose owners have moved on. The sequence below removes the leftovers in an order that keeps the audit trail intact.

1. List every probe, its zone and the last date it contributed items. Probes with no contribution in the review period are candidates for retirement, but confirm with the zone owner first.
2. List the patterns that have produced no items in the review period, and check whether the product they cover is still in use before disabling them.
3. Review the scan ranges and cloud scopes against the current asset register, and flag ranges that no longer hold any live items.
4. Make one change at a time, run a full cycle, and compare the item counts by class with the previous cycle.
5. Record each change with the reason, the expected effect and the date you will check the effect.
6. Only after the reversible changes are settled, review the identification and reconciliation rules with the owner of the CMDB classes.

How to tell tuning has helped rather than hidden something

A tuned discovery program should show fewer wasted runs and a cleaner set of items, but it should not show a sudden fall in the number of items in classes that the business still uses. Track the count of items by class across each change, and treat an unexplained drop as a fault to investigate, not a success to celebrate. Equally, a fall in run time that comes with a rise in errors means the optimization has broken a path, not improved the program.

When the estate is changing too fast to tune

Tuning assumes the estate holds still long enough to be measured. During a large migration, an acquisition or a cloud move, the target list changes faster than a review can follow. Tuning in that period tends to optimize for the estate as it was, which is wrong by the time the change lands. A better course is to freeze the identification rules, keep the scope generous for the duration, and schedule the tuning work for after the migration has settled. The discovery health check service covers an audit of the existing configuration and is a reasonable starting point once the estate is stable enough to measure.

Can we disable a pattern that seems to produce nothing?

Only after you confirm the product it covers is absent from the estate and not simply unreachable. A pattern that matches nothing can mean the software is gone, or that the credentials for those hosts are failing. Check the errors for the target class before disabling anything.

How do we handle probes that serve more than one zone?

Map each zone the probe reaches and assign an owner to each one. A probe with two owners tends to be changed by whichever owner noticed the problem first, and the other zone then loses coverage without warning. Document the mapping in the probe record.

Is it worth tuning cloud discovery separately?

Yes, because cloud scope changes through accounts and regions rather than through the network ranges that on-premises discovery uses. Review cloud scope against the list of accounts the business has approved, and remove accounts that have been closed or whose owner has left, since their integrations are often the first to fail silently.

What should be measured after the first tuning round?

Measure run completion, item counts by class, the number of open data-quality findings and the time the operations team spends on discovery issues each cycle. If the last measure does not fall, the tuning has moved the work rather than removed it.

The rule changes at the hard end of this list need the most care, and the discovery schedule explained guide covers what a schedule controls and how often it runs.