Six layers, one useful depth

The six layers

For each important service, the map inventories:

1. People — roles, scarce skills, minimum headcount, location, on-call
2. Processes — service steps, control points, interfaces between teams
3. Technology — applications, infrastructure, networks, endpoints
4. Facilities — sites, rooms, power, physical access
5. Information and data — datasets, sources, reference data, backups
6. Third parties — suppliers, providers, partners, and their own subcontractors

Layers 1 and 6 produce the most discoveries, and are the ones most often tackled last — when the exercise budget has run out. The order to adopt is the reverse.

How deep to go

The rule: go down to the first non-substitutable element, then stop.

An example. The service depends on an application server. That server is redundant across three machines: substitutable, do not descend. Those three machines depend on a single load balancer: non-substitutable, stop there and qualify the point.

This rule avoids the exhaustive-mapping trap, which yields twenty thousand rows and no decisions.

Tier 2 of third parties

This is the most frequently ignored level, and where the surprises live. Three questions suffice for each critical third party:

1. Who do they rely on to deliver their service — hoster, carrier, software vendor?
2. In what geography is their service produced?
3. Do they share a subcontractor with another of your critical third parties?

The third question is what reveals concentration. Three apparently independent suppliers hosted with the same cloud provider, in the same region, are not three suppliers.

The output format

Not a diagram. A table, one row per dependency:

A table can be sorted, filtered, exported and updated. A boxes-and-arrows diagram is unreadable beyond thirty elements and impossible to maintain.