When dependency maps lie about batch jobs

Architecture diagrams love synchronous APIs. They are easy to draw, easy to version in a repository, and easy to discuss in a review. Overnight batch exchanges are none of those things. They live in scheduler consoles, operations runbooks, and the memory of the person who still restarts a failed job at 03:40.

When we assess enterprise application portfolios in Seoul and nearby delivery centers, the first gap we look for is exactly this: interfaces that only appear when someone asks “what breaks if this application is offline on Saturday night?”

A practical discovery pattern

Start with the scheduler, not the architecture tool. Export job definitions for every system inside your assessment boundary. For each job that reads or writes a file, message queue, or database owned by another team, record the counterpart — even if the counterpart is “unknown shared landing zone.”

Then interview the on-call lead for each application with a single prompt: name the last three times an upstream delay forced you to re-run work. The answers almost always surface exchanges missing from the official map.

What to do with the findings

Do not immediately propose a new integration platform. Rank each discovered exchange by business impact during your next planned change window. Bring that ranked list to the architecture board with owners attached. Dependency analytics only helps when it changes a release decision; otherwise it becomes another unused artifact.

If you are preparing a cutover, treat every unowned batch exchange as a go-live risk until someone claims it in writing.