When teams ask App Architects to analyze application architecture for service dependencies, the first artifact on the table is often a diagram that tries to show everything. The second artifact is usually silence: nobody knows which edges matter for the path that is failing.
Start from a single user action — place order, assign driver, publish article — and ask only three questions at each hop. Who owns this hop? What does it wait on next? What happens when that wait exceeds the budget you care about? Write the answers on the edge, not in a legend nobody reads.
Ignore decorative boxes that never appear in traces for that action. A complete estate map can wait. A useful call chain for one journey is enough to rank bottlenecks and to notice circular dependencies before a release locks them in.
In workshops we print the chain as a vertical list rather than a hairball. Vertical lists force sequence. Sequence is what latency and failure modes follow. Once the sequence is agreed, expanding sideways into sibling services becomes a deliberate choice instead of a panic scribble.