It started with a routine update. 

 

A middleware patch, applied on a Thursday evening. Standard maintenance. The kind of thing that happens dozens of times a year without anyone noticing. By Friday morning, a scheduled job that finance relied on for their weekly reporting had stopped running. Nobody noticed until Monday. By then, the report was three days late, the data was stale, and the finance team had spent the weekend manually pulling numbers from three different systems trying to figure out what happened. 

 

The patch was fine. The middleware was fine. The problem was a dependency nobody had documented – a connection between the patched system and the reporting job that had been built as a quick fix four years earlier and quietly became permanent. 

 

The failure wasn’t in the system that changed. It was in the connection nobody knew how to protect. 

Why dependencies go unmapped 

Software systems accumulate connections the way organisations accumulate processes. Gradually. Pragmatically. Without anyone stepping back to ask whether the whole thing still makes sense. 

 

The integration was built as a workaround in 2019 because the two systems couldn’t communicate directly. The scheduled job that runs at 3 am on assumptions about data structure that haven’t been formally documented anywhere. The reporting layer that pulls from a field that three different teams use in three different ways, for three different reasons, and nobody thought to write any of that down. 

 

None of these are mistakes, exactly. They’re just the natural result of systems evolving faster than documentation does. And the people who built them – who understood exactly why they were built that way – have often moved on. 

 

“It just works, don’t touch it” becomes the operating principle. Until someone touches it. 

The three places it tends to hide 

In our experience, the undocumented dependencies that cause the most disruption tend to cluster in the same places. 

 

Integration points that started as workarounds. These are the connections that were never meant to be permanent but became load-bearing over time. They often don’t appear in any architecture diagram because they were built outside the normal development process – quickly, under pressure, by someone who no longer works there. 

 

Scheduled jobs and automated processes are particularly dangerous because they run quietly in the background and only surface when they fail. The assumptions baked into them – about data formats, field names, timing – are rarely written down anywhere. They just run. Until they don’t. 

 

Reporting layers are the third one. Reports have a way of becoming deeply embedded in how an organisation makes decisions, without anyone formally documenting what they depend on. Change something upstream and the report breaks. Sometimes immediately. Sometimes weeks later, in a way that’s genuinely hard to trace back.

What good dependency hygiene actually looks like 

A full dependency audit every quarter isn’t realistic for most teams. But a living map of critical connections – updated when things change, reviewed before major updates – is achievable. And the difference it makes is significant. 

 

At Mind IT Systems, dependency mapping is one of the first things we do when we start working with a client on modernisation or migration work. Not because it’s the most exciting part of the project (it isn’t) – but because everything else depends on it. You can’t safely change what you haven’t fully understood. 

 

The map doesn’t need to be perfect. It needs to be honest, and it needs to be maintained. 

 

The organisations that handle software changes well aren’t the ones with the most sophisticated tooling. They’re the ones that know what’s connected to what – and have a process for keeping that knowledge current. 

 

When did your team last map what’s actually connected to your most critical system? Not what the documentation says. What’s actually running through it. 

 

Those are often very different things. 

Sujoy Roy
(Head – Digital Marketing)

 

From my teenage time, I had a quench to solve problems and loved leadership. Starting my career in relation management, ignited my passion for managing people. While managing I realized technology needs to be incorporated to keep pace with the changing world & do my work efficiently.