ServiceNow Service Mapping

What ServiceNow Service Mapping does

ServiceNow Service Mapping builds a map of a business application from the top down. You give it an entry point, such as the URL of a customer-facing application. Patterns then follow the connections from that entry point through load balancers, application servers and databases to the configuration items (CIs) underneath.

The output is a service map showing which infrastructure a service depends on. Change advisory boards, incident teams and vulnerability managers all read it, so a wrong map sends every one of them to the wrong decision.

Tag-based maps where each owner tagged only their primary application

Shared servers that support several applications but appear on only one map

Development environments mapped to production infrastructure

Live equipment recorded as in stock or non-operational, so whole rooms look empty

Maps built once and never refreshed after infrastructure changes

Judge change impact

Approvers see every business service that depends on the CI being changed, not only its primary one.

Find causes faster

Incident teams start from the infrastructure beneath the failing service instead of searching for it.

Prioritise by service

Patching follows business criticality because each CI is tied to the services that rely on it.

Show audit scope

In-scope applications carry their underpinning infrastructure, so audit evidence comes from the map.

How we map a service from the top down

The mapping run itself takes little time once the groundwork is right. Most of the effort goes on the steps before and after it.

Agree the services and their criticality. We start from the business applications that matter most, not from the infrastructure list.
Check the CIs underneath. Every server, database and network device a service relies on must exist in the CMDB, in the right class, and be marked live. Equipment recorded as in stock never appears on a map.
Write or extend the patterns. Where a standard pattern doesn't recognise your technology, we write a pattern extension so the connection is found rather than guessed.
Map, then compare with the owner. Each map goes back to the application owner. If it differs from what they believe, one of them is wrong, and we find out which before anyone relies on it.
Connect the map to change and incident. Impact analysis and incident routing read the map, and a refresh schedule keeps it current after infrastructure changes.

What goes wrong without it

On one broadcast estate, a tag-based exercise let application managers tag each component with only the application they considered most important. When a change took a critical device offline, no map showed the other applications that relied on it, and several failed together. A later audit found those applications had no service map at all. We replaced the tagging with top-down, pattern-based mapping.

On an IT estate, a low-priority change was raised against a development environment that had been mapped to the production infrastructure. When the infrastructure was shut down, production went with it.

On a third estate, the client's internal compliance team audited the CMDB and found that most in-scope applications hadn't been identified as in scope, with their infrastructure unlinked. Documenting them correctly cost the client $80,000.

Mapping is only as good as the data under it. Our article on how your CMDB data model affects security, AI and IT performance covers that link, and why change impact analysis is only as good as your CMDB shows what happens to approvals when it fails.

Glass office buildings rising against a blue sky

How Apex helps

Service Mapping only works on CIs you can trust. Our CMDB health baseline scores which configuration items are trustworthy and which are guesses, and gives you a report you can take to your change advisory board. It takes two weeks, and the CMDB health check page explains what it covers.

Our discovery and integration coverage review then establishes what is missing from your estate view, where it is missing, and what that costs during an incident. It covers horizontal Discovery and third-party tool integration, and we scope it with you at an initial consultation.

Book a meeting with a consultant, or start with a CMDB diagnostic call.

Service Mapping questions

What is the difference between Discovery and Service Mapping?

Horizontal ServiceNow Discovery scans the network and records what it finds. Service Mapping starts from a business application and works down to the infrastructure it uses. Discovery gives you the CIs, and Service Mapping shows which of them a service depends on.

Can we map services with tags alone?

Tag-based mapping works when every component is tagged with every application it supports. In practice owners tag the application they care about most, so shared components vanish from the other applications' maps. Top-down mapping finds the connections instead of relying on someone to record them.

How do we know a service map is correct?

Compare it with the application owner's understanding, check every CI on it is live and correctly classified, and test it against a real change before you rely on it. A map nobody has challenged is a guess.

Do we need custom patterns?

Sometimes. Where the standard patterns don't recognise your technology, a pattern extension lets the mapping find the connection. We write these where the estate needs them.

What should be in place before we start?

The CIs a service relies on need to exist in the CMDB, sit in the right class and be marked live. Our CMDB dependency mapping page covers how relationships are recorded.