Preparing application owners for an architecture assessment

A short briefing checklist so interviews during a dependency assessment stay concrete and respectful of delivery calendars.

Two colleagues reviewing documents in a bright office

A dependency assessment succeeds or fails in the interview calendar. If application owners arrive without context, sessions drift into product roadmaps and complaints about tooling. If they arrive over-prepared with fifty slides, you never reach the interfaces that matter.

What we ask sponsors to send one week ahead

  1. A one-page purpose for the assessment and the decision it must inform
  2. The portfolio boundary in plain language — which applications are in, which are explicitly out
  3. Existing diagrams, however outdated
  4. Names of owners who can speak to integrations, not only feature backlogs

What owners should bring to their session

A recent incident involving another system, a list of outbound interfaces they trust, and the interfaces they quietly distrust. We do not need performance benchmarks on day one. We need honesty about handoffs.

Protecting release weeks

In Seoul delivery organizations, assessment interviews often collide with month-end batch cycles. We schedule around those peaks when sponsors warn us early. A two-day delay in interviews is cheaper than forcing a tired on-call engineer to reconstruct dependencies from memory after a night incident.

If you are about to commission an assessment, share this note with owners before the kickoff. The quality of the dependency map tracks the quality of those conversations.

← All field notes