Some recurring problems become so expensive to remove that organisations convince themselves it is cheaper to keep paying for them forever.
For many banks, governments and large organisations, COBOL illustrates this uncomfortable reality.
COBOL was not bad technology that somehow survived.
Quite the opposite.
It was extraordinarily successful at what it was designed to do. It became deeply embedded in business computing, processing transactions and supporting critical operations reliably for decades.
That success created an unexpected problem.
The longer those systems operated, the more the organisation built around them.
Eventually, replacing the technology no longer meant replacing the technology.
It meant disturbing an entire ecosystem.
The Legacy System Is Rarely Just a System
Imagine a core banking platform implemented decades ago.
Initially, it performs a defined set of functions.
Then the business changes.
New products appear.
Regulations change.
Companies merge.
Customer expectations evolve.
Digital channels arrive.
New reporting requirements emerge.
Rather than replacing the core every time something changes, organisations adapt around it.
An interface is added.
Then another.
Data is translated between systems.
Manual reconciliations appear.
Specialist teams emerge.
New applications connect to old applications.
Exceptions require processes.
Processes require controls.
Controls require reporting.
Eventually thousands of dependencies can surround technology that was once relatively self-contained.
The legacy system has become organisational infrastructure.
Every Workaround Makes Tomorrow Harder
This is where the economics become fascinating.
A workaround can be completely rational when introduced.
Replacing a core system to accommodate one new requirement would be absurd.
Build an interface instead.
Problem solved.
Then another requirement appears.
Another interface.
Another workaround.
Another dependency.
Individually, each decision makes sense.
Collectively, they create something nobody deliberately designed.
Twenty years later, leadership asks:
"Why don't we just replace the old system?"
The answer is increasingly uncomfortable.
Because nobody fully understands everything that depends upon it.
The organisation has accumulated risk around the very thing it now wants to remove.
The Cost of Change Starts Protecting the Problem
This is particularly challenging for CEOs.
The legacy environment may be visibly expensive.
Specialist skills are required.
Changes take too long.
Integration is difficult.
Maintenance consumes technology budgets.
New products are harder to introduce.
Operational risk increases.
Everyone agrees something needs to change.
Then someone calculates the cost and risk of replacement.
Suddenly maintaining the existing environment looks attractive again.
Another layer is added.
Another year passes.
The paradox is brutal:
The costs created by the problem become part of the justification for keeping the problem.
This Is Bigger Than Technology
You do not need COBOL anywhere in your organisation to recognise the pattern.
A cumbersome approval process accumulates exceptions.
An ineffective organisational structure develops coordination committees.
A poor customer process creates specialist recovery teams.
An unclear accountability model produces additional reporting.
An acquisition that was never properly integrated creates duplicate functions and systems.
A recurring operational failure generates controls, escalation procedures and manual checks.
Each intervention makes the underlying problem more survivable.
But survivability is not resolution.
Over time, the organisation builds an increasingly sophisticated ecosystem for compensating for something it never actually removed.
Karamawari Can Become Infrastructure
空回り, karamawari, describes effort that fails to translate into meaningful forward movement.
Legacy environments demonstrate how Karamawari can become institutionalised.
People are not standing around doing nothing.
They are working extremely hard.
Teams maintain interfaces.
Specialists reconcile data.
Managers resolve exceptions.
Executives oversee transformation programmes.
Risk teams introduce controls.
Technology teams keep critical systems operating.
Every activity can be necessary.
That is precisely what makes the problem difficult.
The wasted effort no longer looks wasteful because removing any individual piece could cause something important to fail.
The organisation has transformed yesterday's workaround into today's essential process.
Recurring Cost Compounds Quietly
CEOs often assess persistent problems by looking at the visible cost of the latest incident.
That misses the accumulated ecosystem.
The real cost includes everything required to keep the condition tolerable.
People.
Processes.
Controls.
Technology.
Management attention.
Delayed decisions.
Lost agility.
Specialist knowledge.
Integration complexity.
Transformation expenditure.
Opportunity cost.
The original problem may now represent only a fraction of what the organisation is paying.
Most of the cost sits in everything built around it.
And every additional workaround potentially increases the eventual cost of removal.
Find the Workaround Ecosystem
When a recurring problem refuses to disappear, do not look only at the problem itself.
Map what has accumulated around it.
What processes exist because of it?
What roles?
What controls?
What reports?
What meetings?
What technology?
What manual interventions?
What specialist knowledge?
What exceptions?
Then ask the uncomfortable question:
If the underlying problem disappeared tomorrow, how much of this infrastructure would no longer be necessary?
That number may reveal the true commercial value of solving it.
COBOL's longevity offers CEOs a broader lesson that has little to do with programming languages.
Problems accumulate architecture.
Workarounds create dependencies.
Dependencies increase switching costs.
And switching costs encourage another workaround.
Eventually, the organisation is no longer merely paying for the original constraint.
It is paying to maintain an entire ecosystem created because that constraint was never removed.
What recurring problem in your organisation has become so surrounded by workarounds that you are now protecting the infrastructure built to tolerate it instead of eliminating the reason that infrastructure exists?
0 Comments