Mesa Development

Service

Service Mapping Implementation

Typical engagement  ·  6–12 weeks

A service map is only worth having if on-call believes it at 3am. That means entry points that match reality, owners who have actually reviewed their map, and a cadence that catches drift before an incident does.

A corridor between two long rows of identical equipment cabinets.

A service map is a route through an estate like this one — which cabinet, which host, which dependency, in what order.

An application service map A business service resolves through its entry point to the application and infrastructure configuration items supporting it, with one host in a degraded state. Order Management https entry point nginx order-api esx-prod-02 (degraded) ORA-CLUSTER
Order Management
The business service is what the business actually cares about. Everything below it exists to answer "what breaks if this breaks".
https entry point
Mapping starts at the entry point. Getting it wrong produces a map that looks plausible and traces the wrong path.
nginx
The web tier, found by following real traffic rather than by being declared. That is the difference between a map and a diagram.
order-api
Application tiers are where maps stop being maintained, because a deploy changes them and nothing re-runs.
esx-prod-02 (degraded)
The host underneath. When this degrades, a correct map is what tells you which business service is affected — and which is not.
ORA-CLUSTER
Shared infrastructure appears in many maps at once, which is why one duplicate here corrupts several services rather than one.

A business service resolves through its entry point to the application and infrastructure configuration items supporting it, with one host in a degraded state.

  • Order Management — service
  • https entry point — network
  • nginx — application
  • order-api — application
  • esx-prod-02 (degraded) — host
  • ORA-CLUSTER — database
  • Order Management depends on https entry point
  • https entry point depends on nginx
  • nginx depends on order-api
  • order-api depends on esx-prod-02
  • order-api depends on ORA-CLUSTER
An application service map

01

Phases and deliverables

Stated before the work starts, so "done" is not a matter of opinion at the end.

  1. 01

    1–2 weeks

    Select

    • Prioritised list of business services with named owners
    • Entry point inventory

  2. 02

    3–8 weeks

    Map

    • Application service maps built and owner-reviewed
    • Exceptions documented where topology cannot be discovered

  3. 03

    1–2 weeks

    Sustain

    • Review cadence and drift alerting
    • Handover to the service owners

02

What gets measured

Baselined at the start and reported at the end. These are the measures themselves, not claims about past results.

  • m01 Number of business services mapped and reviewed with their owners
  • m02 Percentage of maps with a named owner and a review cadence
  • m03 Map drift detected between reviews
Talk about Service Mapping All services