Application dependency mapping playbook

Technical advisory companion and turnover reference · 6 October 2026 · Draft for client tailoring

Application Dependency Mapping (ADM) makes relationships and uncertainty usable for decisions about a selected application cohort. Its deliverable is a traceable body of evidence, reviewed interpretation and a maintenance handover. It does not install discovery software, prove an entire estate is known, or authorize a migration. This playbook unpacks the existing ADM module and its five deliverables; it changes no scope quantities, commercial terms or engine behavior.

Use the client-approved engagement scope and handling instructions before these templates. Foundations can provide equivalent prerequisite evidence, but purchasing Foundations is not a prerequisite. The client operates collection tools. The consultant works from specifically approved exports or permitted walkthroughs; an existing product license does not authorize an export, transfer or AI submission. Missing permission stops the affected work. No template blank supplies a default commitment.

1. Establish the evidence contract and decision boundary

Begin with the decision the client wants to prepare: whether a retained application can be separated from a database, which relationships need transition investigation, or where an access-design proposal needs further evidence. Record that decision and the applications, assets, locations and security boundaries included. Record exclusions equally explicitly, including external suppliers and shared services that can appear as endpoints without becoming discovery targets. Identify the sponsor, technical reviewers, application owners, source custodians and final artifact acceptance authority separately.

The cohort inventory and evidence dictionary are the first deliverable. Before analysis, agree identifiers and the meaning of each field. Use stable local IDs for applications, components, evidence records and dependency assertions. Maintain native identifiers as aliases with their source scope and effective period. An address or hostname alone is not a durable application identity: reassignment, clusters, proxies and virtual names can join unlike things. Keep unresolved endpoints in an explicit register rather than assigning them to the nearest plausible service.

For each proposed source, document who may obtain it, who may receive it, the exact export boundary, permitted destination, handling marking, approved purpose and retention/disposition authority. Include fields to omit or pseudonymize, where references to restricted originals will remain, and any transfer restrictions. Preserve useful native identifiers only within those instructions. Record timezone, timestamp interpretation, source version, export mode, filters, aggregation, collection period and known loss. Client staff decide whether a further collection or retrieval is allowed; this pack supplies no executable collection commands.

NIST CSF 2.0, dated February 26, 2024, provides relevant outcomes: ID.AM-01/02 address inventories, ID.AM-03 addresses authorized communications/data-flow representations, and ID.AM-04 addresses supplier services. An observed connection is not thereby an authorized flow. These are reference points for the client's selected requirements, not an ADM certification checklist. (CSF 2.0, Appendix A, Asset Management)

NIST SP 800-53 Revision 5 CM-8 is the component-inventory reference. The publication page identifies Release 5.2.0, issued August 27, 2025; record the client's adopted catalog/baseline and applicable requirements rather than assuming every enhancement applies. A map can support evidence preparation; it cannot demonstrate control implementation or effectiveness by itself. (NIST publication and release record, CM-8 in the control catalog)

2. Plan observation around the service's real operating cycles

Use existing inventory, architecture records, owner knowledge and previously approved observations before asking for more data. The client discovery or operations engineer describes what the source actually captures. The consultant records whether it can distinguish application processes, host connections, service endpoints or only aggregate traffic. Keep collection success separate from interpretation success. A populated export can still omit an entire boundary or the process needed to identify an endpoint.

Agree business-cycle questions with owners: ordinary operations, overnight processing, weekly transfers, month/quarter/year-end tasks, maintenance, failover, dormant services, disconnected operation and supplier exchanges. For each cycle, state expected activity, proposed evidence, coverage achieved and what remains unseen. A candidate twelve-week engagement does not promise observation of an annual event. If a required cycle lies outside scope, disclose it and prepare a specific decision to obtain historical evidence, narrow the conclusion or agree separate work.

Assess four dimensions qualitatively: Capture (did the source collect successfully?), Coverage (which cohort, boundary and time were visible?), Resolution (at what identity and relationship granularity?), and Corroboration (what independent evidence supports the interpretation?). Owner validation remains another field. Do not convert these dimensions into an invented readiness score or multiply them into a completeness percentage.

Product behavior matters. Azure Migrate's dependency documentation, updated June 19, 2026, describes TCP observations polled every five minutes and uploaded in batches. Its newer experience can omit unresolved connections from both visualizations and exported CSV; process names are best effort. Thus, request the selected view/export mode and accompanying error/coverage information, and preserve this limitation in conclusions. A thirty-day display/export window is not evidence that all business cycles were captured. Do not instruct a client to change collector privileges or modes without separate authority. (Azure analysis, Azure limitations)

AWS Discovery Agent documentation describes configuration, process and TCP-connection evidence, which is useful when interpreting existing exports. Application Discovery Service closed to new customers on November 7, 2025; its documentation is an existing-tool example, not a purchase recommendation. Product availability, region, government suitability and export permissions must be checked for the actual client environment. (Agent data, Service history)

3. Build a register before drawing conclusions from the graph

Keep the original approved evidence reference and create normalized working records with versioned mappings. Never silently overwrite a conflicting native value. Distinguish the time an event occurred, the interval a record summarizes, the export time and the analysis time. Retain source timezones or document conversion to UTC. Unknown timestamps, interrupted collection and ambiguous endpoint joins remain explicit limitations.

Every dependency assertion gets a stable edge ID, endpoint IDs, relationship type, direction meaning, source references and time/coverage. Define direction in the dictionary: “caller to service” differs from a packet's direction or a statement that one application requires another. For a pair with multiple protocols, processes or purposes, retain distinguishable assertions where combining them would lose decision-relevant meaning.

Use two separate classifications. Evidence kind is declared, observed or inferred. Review status identifies draft, unvalidated, corroborated, conflicting, rejected or superseded interpretations; owner validation is recorded independently. “Observed” means the stated source observed something at its stated grain, not that the business dependency was proven. When declared and observed evidence disagree, retain both assertions and a conflict reference. An inference must identify the supporting records, reasoning, plausible alternatives and evidence that would disprove it.

Treat “not observed” as a qualified observation result, never an automatic absence claim. Establishing that a relationship does not exist needs a specific scope and defensible evidence, not a zero row count. Likewise, connection frequency is not business criticality, an open port does not prove successful business activity, and a common address does not prove common ownership. Escalate identity collisions before using the affected edges for recommendations.

Produce graph views from the register, with a view ID, source version, time window, inclusion filters, aggregation rules and legend. Every visible edge resolves to register records; every omitted category is disclosed. Show unresolved external endpoints and conflicts intelligibly. A simplified briefing view may hide detail, but must link to the underlying register and disclose the simplification. Avoid a visually authoritative “complete map” label when evidence is partial.

4. Validate business meaning and separate hubs from coupled groups

Prepare focused owner review packets rather than asking “is this diagram correct?” Ask what the relationship does, when it runs, whether it is synchronous, what happens if unavailable, whether another path exists, and which recovery, latency or data-consistency constraints matter. Ask the relevant technical specialists to challenge the interpretation. Record the respondent's role and authority, response date, supporting reference and unresolved disagreement. Technical corroboration does not impersonate the accountable application owner's validation.

Use shared identity, DNS, monitoring, backup and management services as contextual hubs. Retain their edges in the full record, but distinguish them from candidate grouping constraints. AWS wave-planning guidance warns that shared services can connect the entire scope and that network data alone does not establish latency tolerance or hard coupling; owner and support-team discussion is needed. This supports a disciplined question, not automatic move-group generation. (AWS dependency-group guidance)

For each candidate group, state the constraint that could require coordination, the supporting evidence, alternatives and unknowns. Shared hosting, a common owner or frequent traffic can justify investigation but does not by itself require simultaneous movement. Conversely, an infrequent settlement task may be critical despite a sparse graph. Keep infrastructure coupling, data consistency, maintenance constraints and organizational preferences distinguishable.

Give owners a clear choice of recorded responses: confirm the stated meaning within scope; correct it with evidence; dispute it; identify the appropriate owner; or leave it unresolved. Non-response remains unvalidated. Assign unresolved material issues a responsible action owner and next evidence request, with a date only when agreed. Do not resolve a conflict by majority vote or by favoring the newest tool automatically.

5. Turn evidence into conditional options using current capabilities

The transition decision deliverable presents options for further investigation, retention, separation or coordinated planning. Each option names the affected cohort and edges, evidence currency, assumptions, constraints, benefits sought, unresolved questions and the authority required before action. It is not an approved migration wave, network rule, security boundary or business case. State what new observation or owner correction would reverse the advice.

Inventory the client's existing working methods. A controlled spreadsheet, diagram tool and approved evidence store can be sufficient for a bounded cohort if identifiers, provenance, versioning and review are maintained. Existing CMDB/discovery capabilities may supply stronger repeatability, but their schema, filters and ownership need validation. A CMDB-shaped export is a documented handover file, not an integration or synchronization commitment.

Where capability is missing, distinguish an interim method from a future requirement. The interim method should identify the manual work, fidelity limits and receiving owner. Future selection criteria can include source coverage, relationship granularity, unresolved-endpoint handling, export fidelity, auditability, access controls, government-region support, retention and operating cost. Avoid recommending a new platform simply because it draws a richer graph. Installation, procurement and recurring collection remain separately authorized work.

Read-only AI can propose identity questions, summarize cited disagreements or adapt an agreed template to an existing tool's documented fields. It may not merge uncertain identities, fabricate edges, mark an owner response, accept a deliverable or execute a query against a client system. The prompt pack requires approved inputs and exact handling/export authority; where those are absent, use empty schemas and public documentation only. Any client-facing draft receives human review.

6. Hand over five deliverables and a workable refresh method

Package the cohort/dictionary, dependency register/graph, coverage assessment, validation/conflict log and transition/maintenance handover with a common version index. Record which editable files are included, their identifiers, evidence references, handling restrictions, known gaps and receiving custodians. Keep restricted raw material in its approved location; a locator is sufficient only when the authorized recipient can resolve it. Do not copy restricted source material merely to make the package appear self-contained.

Review against the existing module's criteria: stable identities and explicit ownership gaps; traceable edges and filters; honest cycle/coverage limits; recorded dispositions or open actions; and maintainable options. Submit a criteria matrix with the exact artifact versions. Review comments distinguish an in-scope deficiency from a new request. Record corrections and unresolved items without changing the original evidence silently.

Written artifact acceptance belongs to the named client authority and identifies version and criteria. Silence, attendance, payment or use of a draft is not acceptance. Partial acceptance identifies exactly what remains open. Accepting a well-disclosed gap register does not accept the underlying operational risk, authorize a migration, or waive a control requirement.

The receiving custodian needs a repeatable refresh procedure: identify the triggering change or agreed review date; confirm collection/export permission; obtain the approved delta or snapshot; preserve prior versions; reconcile identifiers and time; update affected assertions; reissue changed graph views; request owner review where meaning changed; and record supersession. Define who checks service onboarding, retirement, address reassignment, provider changes and changed business cycles. No recurring consultancy or collection obligation arises unless separately agreed.

The reusable templates and prompts reside in plus-delivery/turnover/adm/. They contain no client facts. Adapt field names to the common turnover contract through a documented mapping; keep module-specific evidence, coverage and validation distinctions intact. The final useful outcome is a client-owned record that explains what is known, what remains uncertain and who can decide the next step.