ServiceNow Service mapping

You give Service Mapping an entry point (a URL, a load balancer). It follows the real traffic and configuration down each tier, building a dependency map into the CMDB:

The phrase top down is doing real work here, so it is worth unpacking against the alternative. Bottom up is what discovery does: find everything on the network, then try to infer which things belong together. It produces a complete inventory and a guess at the services.

Top down starts from an entry point that a human names, usually a URL or a load balancer address that represents a service people care about. From there the tooling follows the actual traffic: this web server talks to that application server, which talks to that database. Each hop is observed rather than assumed.

The result is a map of one service that is genuinely connected, built from evidence, rather than a diagram somebody drew. And crucially it stops at the boundary of that service, so you get the fifty components that matter instead of the fifty thousand that exist.

Choosing entry points is the part that needs a business conversation rather than a technical one. The service catalogue people already talk about is the right starting list: payroll, order entry, the customer portal. Starting instead from the applications the infrastructure team knows produces maps of things nobody outside IT recognises, which then cannot be used to set incident priority, because nobody can say what the component is worth.

A day for the first one, and it teaches more than any amount of reading about patterns.

1. Choose a service somebody would notice if it stopped, and find its entry point: the URL users hit, or the load balancer address.
2. Confirm the credentials and the MID Server can reach every tier the service touches. This is where most first attempts fail, and it fails silently as an incomplete map.
3. Run the mapping and watch it build. Note where it stops, because that is a tier it could not see into.
4. Now take the finished map to somebody who runs the application and ask what is missing. There will be something.
5. Look at what it found that you did not expect. A dependency nobody knew about is the most valuable output of this entire exercise.
6. Record which components were found automatically and which you added by hand, because the hand added ones will not update themselves.

Step five is the reason to do this at all. Services in a real estate depend on things nobody documented, and the first map of a service almost always surfaces one.

The two are complementary rather than alternatives, and the usual sequence is discovery first. Discovery populates the infrastructure layer with the hosts, the databases and the software, which is what mapping then draws lines between. Attempting service mapping on an estate discovery has not covered produces maps full of components the CMDB has never heard of, each of which has to be created as it is found, and the result is slow and full of near duplicates.

The division of labour is worth remembering as a sentence: discovery finds the things, mapping finds the relationships, and only a human can say which collection of things is a business service that somebody cares about.

Two failure shapes cover most of what goes wrong, and telling them apart saves a lot of time.

The map stops at a tier. The pattern ran, could not identify what it found, and stopped. Usually credentials, a missing pattern for that technology, or a connection the MID Server cannot make. The map is short and the missing part is obvious.

The map is wrong rather than short. A pattern matched something it should not have, or a shared component such as a database cluster pulled in dependencies belonging to a different service. The map looks complete and it is not true, which is worse, because people will act on it.

The second is why review by somebody who knows the application is not optional. Automated mapping is evidence, not truth, and the person who runs the service can spot a wrong edge in seconds where you would spend an afternoon.

Credentials deserve their own mention because they are the most common cause of a short map and the easiest to fix. Mapping needs to log in to each tier to see what it connects to, which means an account on the web server, on the application server and on the database, with enough rights to read the configuration. Getting those provisioned across three teams is usually the longest part of the first mapping.

With an accurate service map, a single failed CI immediately shows which business services are at risk, powering change impact analysis, event correlation and outage prioritisation. It turns "a server is down" into "the checkout service is degraded".

Being concrete about the payoff, because this is expensive work and it has to be justified.

Change impact. A change on a server can name every service affected, which turns a change advisory conversation from opinion into a list.

Incident triage. An alert on infrastructure becomes an alert on a business service, and priority follows from what the service is worth rather than from what the device is.

Event correlation. Twenty alerts across a service's tiers collapse into one incident about the service, which is the difference between a noisy console and a useful one. See event management.

All three depend on the map being trusted. A map that is 70 percent right gets ignored after the second time it misleads somebody, and the work that produced it is wasted. This is the argument for mapping fewer services properly rather than many services approximately.

• Mapping too many services by hand instead of using patterns.
• Poor entry-point definition, so maps are incomplete.
• Letting maps go stale after infrastructure changes (defeats the purpose).
• Mapping services no one uses for impact, wasting effort.

Version note: the mapping capability has been through more than one generation, and the tag based approach that supplements traffic based discovery in cloud environments is a comparatively recent addition. Containerised and cloud native workloads in particular are mapped differently from the classic three tier application this material describes. Check what your instance supports before promising coverage of a platform. See tag based mapping.

Two more worth naming, both about scope. Mapping everything at once, which produces a programme that runs for a year and delivers nothing usable in the meantime. Mapping ten services that matter, properly, is worth more than partial coverage of two hundred. And treating a map as finished: applications change, and a map nobody re-runs and nobody reviews becomes wrong at about the speed the estate changes. Assign the review the way you would assign any other data ownership, per service, to the team that runs it.

Mapping your first service takes a day, and building a set of maps that a change process will actually rely on is the work the course covers.