The Workload Automation Paradox

8 March 2026

The infrastructure that runs everything — and nobody audits.

Somewhere in your building — or more likely, in a data centre you've never visited — there is a system that runs hundreds, maybe thousands, of automated tasks every night.

It moves files between systems. It triggers batch processing that reconciles transactions, generates reports, calculates balances, feeds downstream applications. It orchestrates the sequence in which things happen — which job runs first, which waits for the other to finish, what happens when something fails at 3 AM.

This system is called a workload automation platform. In many organisations, it's BMC Control-M. In others, it's IBM TWS, Stonebranch, or something built in-house with cron and shell scripts.

It is, without exaggeration, the nervous system of your operations.

And almost nobody audits it.

The paradox

Enterprise IT audits everything. Servers are inventoried. Networks are monitored. Databases have capacity reports. Applications have SLAs. Code goes through review before deployment.

But the layer that orchestrates all of these — the workload automation layer — sits in a governance blind spot. It was set up years ago. It works. It runs every night. And because it works, nobody questions it.

Until someone asks the questions that should have been asked years ago.

What we found

Over the past several years, I've audited workload automation environments in organisations across critical infrastructure, payments, and energy. The environments varied in size, industry, and technology. The findings didn't.

Here is what a typical diagnostic reveals — and I say typical because the numbers are composites, but the patterns repeat with uncomfortable consistency.

38% of jobs have no documented owner. The job runs. It does something. But if you ask "who is responsible for this job?" — nobody can answer. The person who created it left years ago. The team that inherited it treats it as somebody else's problem. It exists in a zone of collective amnesia: too risky to delete, too obscure to understand, too boring to investigate.

15% of active jobs serve no current business process. They were created for a project that ended. Or a system that was decommissioned. Or a regulatory requirement that changed. But the job is still there. Still running. Still consuming resources. Still generating alerts that operations teams dutifully acknowledge every morning without understanding why.

Dead jobs are not just waste. They're noise generators. Every false alert trains the operations team to ignore alerts. And the day a real alert fires — a job that actually matters — it drowns in a sea of alerts that haven't meant anything for years.

The batch window has grown by 40–50% over three years, and nobody noticed. When the environment was designed, the nightly batch ran from midnight to 5 AM. Five hours. Comfortable margin. Today, it runs from 11 PM to 7 AM. Eight hours. And some nights it bleeds into business hours, because someone added "just one more job" every quarter for three years.

Nobody planned this. Nobody measured it. The batch window didn't explode — it crept. Like a frog in slowly heating water. By the time someone notices, the margin is gone.

Zero recovery procedures have been tested in the last 24 months. The jobs have error handling. Some have retry logic. A few have notification rules. But the question "if job #247 fails at 3 AM and nobody is available, what happens?" has no tested answer.

I don't mean there's no runbook. There might be. I mean nobody has verified that the runbook actually works with the current infrastructure. Because the infrastructure has changed — servers were migrated, file paths were updated, service accounts were rotated — but the recovery procedures were never re-tested against the new reality.

The dependency chain nobody mapped

Here is what makes workload automation uniquely dangerous to leave unaudited: dependencies.

Job A triggers Job B. Job B waits for a file from System C. System C generates the file only after Job D completes. Job D depends on a database extract from System E. System E is maintained by a third party who changed their SFTP configuration six months ago without telling anyone.

This chain exists. It runs every night. It works — until one link changes.

And when it breaks, nobody can tell you why, because the chain was never documented. The person who built it understood the full picture. That person retired. The team that inherited it understands their piece — Job A, or Job B — but not the chain. Not the dependencies. Not the timing constraints.

Most organisations discover their dependency chains during an incident. At 3 AM. With the business waiting.

Why this happens

Workload automation is infrastructure that was built to be invisible. When it works, nobody thinks about it. When it breaks, somebody fixes it and everybody goes back to not thinking about it.

There is no annual review. There is no scheduled audit. There is no compliance requirement — yet — that specifically mandates workload automation governance. DORA and NIS2 are changing this, but most organisations haven't connected the regulatory requirements to the batch environment.

The result is an infrastructure layer that grows organically, accumulates debt silently, and delivers risk that only becomes visible during failure.

It is the exact opposite of every other layer in enterprise IT, where visibility, governance, and accountability are standard practice.

The cost of not looking

I've seen organisations spend months troubleshooting recurring batch failures that could have been prevented by a 3-day audit. I've seen batch windows that consumed so much of the nightly processing time that the organisation had to buy additional server capacity — not because the workload grew, but because the schedule was never optimised.

I've seen teams of five people doing overnight standby for an environment where 80% of the alerts were for jobs that hadn't mattered in years. Five salaries. Standby allowances. Weekend coverage. For noise.

The cost of not auditing your workload automation isn't a single catastrophic failure. It's a slow, continuous bleed: wasted capacity, wasted alerts, wasted human attention, and a growing vulnerability to the one failure that actually matters.

The question

Every organisation I've worked with has the same reaction when I present these findings: "We knew some of this. We just never had the data."

That's the paradox. The information is there. The environment logs everything. The platform stores every definition, every dependency, every execution history. The data exists.

What doesn't exist is someone who stops, looks at the full picture, and asks the questions that operations teams are too busy — or too habituated — to ask.

Questions like:

How many of your batch jobs have a documented owner — and how many are orphans running on institutional inertia?

When was the last time your recovery procedures were tested against the infrastructure that exists today — not the infrastructure that existed when they were written?

How much of your batch window is consumed by jobs that no longer serve a business purpose?

If the person who built your most critical batch chain left tomorrow, who would understand the full dependency map?

If you can answer all four with confidence, you're in the minority.

If you can't — that's not a failure. It's a diagnostic waiting to happen.