The data mapping exercise, without the exercise.
Somebody has asked where customer data lives. The usual answer is a six-week project of workshops and spreadsheets, producing a diagram that is already out of date.
You are asking people to remember a system.
Engineers describe the parts they wrote, as of the last time they looked. Nobody describes the debug log they added on a Friday two years ago.
The map is a document, the system is not. Every release moves them apart and nothing tells you by how much.
A workshop cannot surface a path nobody thought to mention. Those paths are exactly the ones that matter.
Read out of the repository, in an afternoon.
Connect a repository and the map is derived: every classified field, every hop, every store, log and third party it reaches. You correct what the engine got wrong once, and that correction sticks across every view and every future scan.
It says what it could not resolve.
Static analysis cannot follow every outbound call, and systems that were never in your repository are invisible to it. Rather than quietly omit those, the map states how many calls it could not resolve and gives you a canvas to place the systems you know about. A map that hides its own gaps is worse than a slow one.