Early in my assessment work I captured integrations the way most people do. What system does it connect to, what data does it move, how is it triggered. Direct connections, clearly recorded. It looked complete.
Then a change that had been assessed as contained took down a system nobody had connected to it. The integration we changed talked to system A. System A fed system B through a path that was not on anyone's diagram. The change rippled, and the first anyone knew of it was system B falling over.
The change was not wrong. The assessment was incomplete. We had recorded what the integration connected to directly, and nothing about what those connections in turn touched. So I added a field to every integration assessment I have done since. It asks a single question: what else does this affect.
It sounds almost too simple to matter. It is one of the most valuable fields I capture.
The reason is that the direct connections are the easy part. Everyone can tell you what an integration obviously talks to. What nobody volunteers, because it requires stepping back and thinking about the whole, is the second-order reach. The system that consumes the output of the system you are changing. The report that breaks if a field shifts. The downstream process that assumed a file would arrive by nine and silently fails when it does not. None of that shows up if you only record direct connections.
The also-affects field forces the question every single time. You cannot fill it in without asking yourself what sits downstream, and asking the question is most of the value, because it surfaces dependencies that were always there and never written down. Sometimes the answer is genuinely nothing, and that is worth knowing too. Often the answer is two or three systems nobody had connected to the change in their heads.
This matters most in a migration, where the whole game is sequencing. You cannot order a cutover safely if your map only shows direct connections, because the thing that breaks will be the indirect dependency you never captured. Knowing that changing integration X also affects systems B and C is the difference between a cutover you sequenced correctly and an outage you are explaining afterwards.
The blast radius of a change is almost never limited to the thing you are changing. The also-affects field is a small, cheap habit that forces you to map the radius before you find it the hard way.