There are things we depend on every day without giving them much thought.
We expect the electricity to work when we switch on a light. We expect to be able to pay for something with a card. We expect our phones to connect, deliveries to arrive, and the systems behind these services to keep running.
Most of the time, they do.
And because they work, we gradually organise more of our lives around them.
That is where an interesting problem begins.
Imagine a business that has used the same payment system for years.
It works well. Staff know how to use it. Customers rarely experience problems. Over time, the business stops keeping cash on the premises, removes older equipment and changes how it handles transactions.
None of those decisions seems unreasonable.
But the business has changed. It now depends on that payment system in ways it didn't before.
If the service becomes unavailable, the problem isn't simply that a payment terminal has stopped working. The business may have lost the practical ability to take payments at all.
The system hasn't necessarily become less reliable.
The consequences of losing it have become greater.
Something similar can happen across much larger systems.
An organisation moves its records into a shared digital service. A transport operator relies increasingly on centralised scheduling. A company replaces several communication arrangements with one platform that does everything it needs.
These changes can make daily operations easier. They may reduce costs, improve coordination and remove unnecessary work.
But older arrangements can disappear along the way.
Equipment is retired. Staff who understood previous methods leave. Procedures are no longer practised. Eventually, an alternative may still exist in theory but be difficult to use in practice.
There doesn't have to be a single decision to abandon it.
Sometimes an alternative disappears because nobody has needed it for a long time.
A system can be highly reliable and still create a difficult dependency.
Reliability concerns how consistently something performs its intended function.
Resilience also concerns what happens when that function is interrupted, and whether the people depending on it can adapt.
The distinction matters.
A payment network might operate successfully for years, but that record alone doesn't tell us whether businesses could continue trading during an extended interruption.
A communications service might rarely fail, but that doesn't establish whether its users have another practical way to coordinate if it becomes unavailable.
A reliable service can reduce the number of problems people experience while increasing the consequences of the problems that remain.
These two things can happen at the same time.
The difficult part is that growing dependence doesn't always look like a problem.
It can look like progress.
Services become faster. Processes become simpler. Costs fall. People no longer have to maintain equipment or arrangements they seldom use.
The benefits are real.
But as dependence grows, the questions surrounding a service begin to change.
It is no longer enough to ask whether it works well.
We also need to understand what now relies on it, what alternatives remain, and how much could continue if it were suddenly unavailable.
Those questions can be difficult to answer because the dependency may have developed gradually, through hundreds of ordinary decisions.
No single decision created the whole problem.
There is nothing inherently wrong with depending on a reliable system. Modern life would be difficult without shared infrastructure and services that work consistently.
The concern is whether we recognise how much has come to depend on them.
A service that was once convenient may eventually become essential. An alternative that once seemed unnecessary may turn out to have been more valuable than anyone realised.
And the longer something works without interruption, the easier it can become to forget how much would stop if it didn't.
Perhaps the question isn't simply how reliable a system has become, but how much of everything around it now assumes that it will always be there.
Related reading: Dependency Concentration · Fragile Redundancy · Operational Complexity · Issue 02 — When Redundancy Isn't Really Redundancy