← Outside the Rack. Inside the WAN.

What If We’ve Been Engineering Resilience Backwards?

Outside the Rack. Inside the WAN. | Tuesday: Founder’s Log

By John Klein | Founder & CEO, Atlas Global | Contributor, Outside the Rack. Inside the WAN.

I’m getting tired of watching data centers take the blame for America’s energy problems.

Everywhere we look, there’s another debate about artificial intelligence, cloud computing, and the enormous electricity demands of modern data centers.

And yes, those demands are real.

I’m not going to pretend that data centers don’t consume tremendous amounts of electricity. They do. Nor am I suggesting that every proposed development is economically justified, environmentally responsible, or appropriate for the community where it’s being built.

But I think we’re having the wrong conversation.

Instead of simply asking why data centers need so much electricity, perhaps we should be asking why our infrastructure is struggling to accommodate an economy we’ve spent decades building.

The digital economy isn’t coming. It’s already here.

And whether we’re talking about hospitals, telecommunications networks, financial institutions, emergency services, manufacturing, or the electrical grid itself, our dependence on digital infrastructure is only increasing.

Yet we continue to approach the resilience of these systems largely as separate engineering problems.

That, to me, is the bigger issue.

We’ve interconnected our infrastructure far more extensively than we’ve interconnected our approach to resilience.

And I believe that disconnect deserves considerably more attention than it’s receiving.

We Built a Digital Economy on an Aging Foundation

Consider the American electrical grid.

Much of its underlying infrastructure evolved over generations of investment, expansion, modification, and repair.

It wasn’t originally designed around today’s cloud computing environments, electrified transportation, distributed generation, or the computational demands of artificial intelligence.

Of course, the grid has been modernized repeatedly. New transmission technologies, sophisticated control systems, improved generation capabilities, and substantial infrastructure investments have transformed how electricity is produced and delivered.

But modernization and fundamental redesign aren’t necessarily the same thing.

Following World War II, countries such as Japan and parts of Europe faced enormous reconstruction challenges. In some cases, rebuilding created opportunities to replace destroyed infrastructure with newer systems.

The United States faced a different situation. Much of our domestic infrastructure remained intact.

That was an extraordinary economic advantage at the time.

But it also meant that subsequent generations often expanded and modified existing infrastructure rather than rebuilding entire systems from the ground up.

I’m not suggesting that postwar reconstruction automatically produced better infrastructure elsewhere, or that the United States somehow stopped modernizing its grid.

I’m asking whether we’ve spent too much time adapting yesterday’s infrastructure to tomorrow’s demands without sufficiently reconsidering the architecture underneath it.

The Department of Energy has identified substantial transmission expansion needs as electricity demand grows, new generation comes online, and congestion challenges existing networks.

Meanwhile, Lawrence Berkeley National Laboratory’s June 2026 assessment projects that data centers could account for approximately 9.5% to 15.3% of U.S. electricity consumption by 2030, with a central estimate of 11.8%.

Those are serious numbers.

But here’s where I think the discussion goes off track.

Growing electricity demand and inadequate infrastructure investment are different problems, even when they collide.

Data centers should pay their fair share of the infrastructure required to support them. They should be accountable for their consumption, improve efficiency wherever practical, and explore ways to contribute to grid stability rather than simply drawing power from it.

But we shouldn’t pretend that eliminating data center growth would somehow resolve every underlying problem facing America’s electrical infrastructure.

Transmission constraints, aging equipment, extreme weather exposure, regional capacity limitations, and the complexities of integrating new generation resources deserve attention in their own right.

And the relationship between energy and digital infrastructure is becoming increasingly reciprocal.

The grid needs telecommunications networks.

Utilities depend on computing infrastructure, monitoring platforms, digital protection systems, and operational control networks.

Data centers depend on electricity.

And the organizations responsible for managing electricity increasingly depend on the same digital economy they’re being asked to support.

So where does the electrical grid end and digital infrastructure begin?

From an operational continuity perspective, that boundary is becoming increasingly difficult to draw.

And that’s precisely the point.

We’ve Built Interconnected Systems but Still Think in Silos

Consider what it takes to keep a hospital operating.

It needs electricity, telecommunications, computing infrastructure, medical equipment, cybersecurity, water, transportation, logistics, and qualified personnel.

Many of those capabilities depend on systems and services operated by entirely different organizations.

Now consider a data center.

It needs power, cooling, connectivity, physical security, hardware, software, personnel, and a dependable supply chain.

The utility supplying its electricity may depend on telecommunications networks and digital control systems.

The telecommunications provider may depend on data centers for network management and supporting services.

And the hospital may depend on all three.

The dependencies don’t move in one direction. They form a network of interdependence.

Yet we frequently evaluate these industries separately.

Utilities have their engineering and reliability standards. Telecommunications providers have theirs. Healthcare organizations operate within their own regulatory frameworks. Data centers follow established design and operational classifications.

Those standards matter.

But a collection of individually resilient components does not automatically produce a resilient end-to-end system.

And that brings me to one of the fundamental questions I believe our industry needs to confront.

What exactly are we measuring when we claim something is resilient?

Are We Measuring Infrastructure or the Mission It Supports?

The Uptime Institute’s Tier classification system has played an important role in establishing consistent expectations for data center infrastructure.

Tier III emphasizes concurrent maintainability. Tier IV adds fault tolerance for defined site-infrastructure failures.

Those are meaningful engineering achievements, and I have no interest in dismissing them.

But a highly resilient data center doesn’t automatically guarantee the availability of every service that depends on it.

What happens when the telecommunications network fails?

What happens when a shared identity service becomes unavailable?

What happens when a regional power disturbance affects multiple supposedly independent facilities?

What happens when a software update propagates across an entire distributed environment?

Or when the data center remains fully operational, but the hospital depending on it cannot access its clinical systems?

The facility may be performing exactly as designed.

The mission may still be failing.

That’s an important distinction.

We need to stop confusing the resilience of an individual facility with the continuity of the services that facility supports.

This isn’t an argument for abandoning existing standards.

It’s an argument for connecting them and examining what happens at the boundaries between them.

Because those boundaries are often where an otherwise impressive resilience strategy begins to unravel.

When Redundancy Becomes Another Source of Risk

For decades, we’ve approached resilience by adding redundancy.

Additional servers. Additional network paths. Backup generators. Secondary facilities. Multiple providers. Geographic distribution.

And redundancy absolutely has its place.

But there’s something we don’t discuss nearly enough.

Every additional component introduces something else that must be configured, maintained, monitored, secured, and understood.

When redundant components are genuinely independent, they can dramatically improve resilience.

But when they share hidden dependencies, we may simply be building a larger failure domain without realizing it.

Imagine an organization operating 100 facilities across multiple regions.

Each location has redundant power and connectivity. The organization has invested heavily in geographic diversity.

On paper, the architecture looks impressive.

But what happens if all 100 facilities rely on the same centralized control plane?

The same identity platform?

The same orchestration system?

The same software deployment process?

Suddenly, 100 geographically distributed facilities may be vulnerable to a single shared failure.

We’ve multiplied our infrastructure without necessarily multiplying our independence.

And as the environment becomes more complicated, those relationships can become increasingly difficult to identify.

The answer isn’t less redundancy.

It’s better-engineered redundancy.

Redundancy with explicit failure-domain boundaries, independently validated operating capabilities, and a clear understanding of what happens when the assumptions behind the architecture stop holding.

Because redundancy that fails alongside the system it’s supposed to protect isn’t much of a safety net.

The Absence of an Outage Is Not Proof of Resilience

Imagine an organization that hasn’t experienced a significant outage in seven years.

Management is pleased.

The uptime reports look excellent.

Technology providers point to those numbers as evidence of success.

And perhaps they should. Seven years of reliable operation is an accomplishment.

But during those seven years, how much has changed?

How many experienced employees retired?

How many systems were replaced?

How many additional locations came online?

How many software platforms became interconnected?

How many contingency plans were updated but never meaningfully exercised?

And how many employees have never experienced a serious operational failure?

The organization may have become considerably more complicated during those seven years.

Its dependencies may have expanded.

Its institutional knowledge may have diminished.

Its recovery procedures may no longer reflect the systems actually in production.

Yet its historical uptime continues to look excellent.

The absence of an outage is not proof that a system can withstand one.

Reliability and resilience are related, but they aren’t interchangeable.

Reliability concerns the ability to perform as expected over time.

Resilience concerns the ability to withstand disruption, adapt, and preserve or restore essential functions.

A system can demonstrate excellent historical reliability while remaining vulnerable to a failure scenario it has never encountered.

And that’s why I believe resilience must be continuously demonstrated, not merely inferred from historical performance.

A system that has never failed may be exceptionally well engineered.

Or it may simply never have encountered the conditions capable of exposing its weaknesses.

We shouldn’t confuse the two.

Human Competence Is Part of Critical Infrastructure

This may be the part that concerns me most.

We’ve built generations of increasingly technology-dependent workflows.

Computers help doctors make clinical decisions. Digital systems coordinate emergency responses. Automated platforms manage infrastructure that once required substantial manual intervention.

These advances have improved capabilities, increased efficiency, and, in many circumstances, saved lives.

But what happens when the technology disappears?

What happens when a hospital loses access to its electronic health records?

When emergency dispatch loses its computer-aided systems?

When responders lose digital mapping or normal communications?

We’ve all watched fictional television scenes where an experienced doctor, firefighter, or emergency responder falls back on years of practical knowledge to keep working when the technology fails.

Those scenes resonate because they highlight something very real.

There’s a difference between knowing how to operate a system and understanding the work that system performs.

As experienced personnel retire, organizations risk losing institutional knowledge that may not be adequately captured in procedures or training programs.

That doesn’t mean younger professionals are less capable.

It means many have entered professions where digital workflows are the normal operating environment, and opportunities to practice without those systems may be limited.

A hospital can have a perfectly documented downtime procedure that becomes nearly useless if its personnel have never practiced it.

An emergency communications agency can maintain backup radios that provide little protection if responders don’t know how to coordinate effectively with them.

A utility can maintain manual operating procedures that become increasingly difficult to execute if the people who understood them are no longer available.

Human competence is part of critical infrastructure.

And if we fail to preserve it, no amount of technological redundancy can fully compensate.

Training, institutional knowledge, operational exercises, and the ability to function in degraded conditions must be treated as engineering requirements, not optional administrative activities.

Moving Infrastructure Doesn’t Eliminate Responsibility

Another major transformation in the digital economy has been the movement toward off-premises infrastructure.

Cloud computing, colocation, managed services, and outsourced technology operations have changed how organizations acquire and operate critical systems.

And there are legitimate reasons for that.

Specialized providers can offer expertise, infrastructure, geographic reach, and operational capabilities that many organizations would struggle to reproduce independently.

I’m not opposed to those models.

But I am opposed to the assumption that moving infrastructure somewhere else automatically solves the underlying problem.

Because often, it doesn’t.

It changes the dependencies.

It changes who operates the equipment.

It changes where the infrastructure lives.

It may improve some risks while introducing others.

But it does not eliminate the customer’s responsibility for the outcome.

A hospital can outsource its electronic health records infrastructure.

It cannot outsource its obligation to care for patients.

A utility can contract with technology providers.

It cannot simply walk away from its responsibility to deliver essential services.

We’ve surrendered some control while sometimes convincing ourselves we’ve transferred responsibility along with it.

And that’s a dangerous misunderstanding.

The provider may control the infrastructure.

The customer still has to live with the consequences when the service fails.

This deserves a deeper discussion of its own, particularly regarding how cloud services are marketed, purchased, implemented, and governed.

We’ll get into that next week.

Standards Should Provide a Path, Not Just a Destination

There’s another issue I’ve encountered while examining how different industries approach security, reliability, and continuity.

We frequently establish requirements without providing organizations with a sufficiently clear and practical path to achieve the intended outcome.

Consider healthcare.

The HIPAA Security Rule establishes important requirements for protecting electronic health information, including risk analysis, safeguards, and contingency planning.

It is deliberately flexible and technology-neutral.

That flexibility serves a legitimate purpose.

A small medical practice and a major hospital system should not necessarily be required to deploy identical technical architectures.

But flexibility also creates an implementation challenge.

Organizations still have to translate regulatory requirements into workable systems, procedures, training, and measurable outcomes.

Additional guidance exists, including resources from NIST, but implementation can remain complicated for organizations whose primary expertise is delivering healthcare rather than engineering information systems.

I believe there’s an important lesson here.

Technology neutrality should not mean implementation ambiguity.

We should be able to preserve flexibility while offering clearer pathways for identifying dependencies, selecting safeguards, validating performance, and demonstrating operational readiness.

And we need to recognize that security compliance, infrastructure reliability, and operational continuity are related objectives, not interchangeable guarantees.

An organization can satisfy a regulatory requirement and still experience a catastrophic interruption.

That doesn’t necessarily mean the regulation failed.

It may mean we expected a compliance framework to answer an engineering question it was never designed to answer.

The Answer Isn’t Another Industry to Blame

It’s easy to criticize utilities for aging infrastructure.

It’s easy to criticize data centers for electricity consumption.

It’s easy to criticize hospitals for outdated technology or cloud providers for service disruptions.

But that approach misses something important.

These industries operate under real constraints.

Regulations. Capital requirements. Public safety obligations. Security concerns. Legacy systems. Procurement processes. Operational risk.

A utility cannot casually replace major infrastructure overnight.

A hospital cannot experiment recklessly with systems that support patient care.

A telecommunications provider cannot redesign an interconnected network without considering the consequences for customers and other operators.

And a data center cannot solve every upstream infrastructure problem by itself.

That’s why I believe the solution must begin with partnership.

Not another exercise in assigning blame.

Not another marketing campaign promising that one product or platform will solve everything.

And not another standard developed in isolation from the industries it affects.

We need a more coordinated approach that connects existing standards, identifies shared dependencies, establishes practical implementation pathways, and measures continuity across the entire service chain.

This is one of the ideas influencing our work on a proposed Global Resilience Framework at Atlas.

That framework remains a development objective, not a demonstrated industry-wide solution. Its eventual value will depend on rigorous engineering, collaboration, testing, and independent scrutiny.

The objective isn’t to replace every existing framework.

It’s to explore how they can work together more effectively.

Because the real problem doesn’t respect organizational boundaries.

Neither should our approach to solving it.

What If We’ve Been Looking at the Problem Backwards?

While developing Atlas, I kept returning to a fundamental question.

Why do we spend so much effort planning how to recover after critical services stop operating, rather than placing greater emphasis on engineering those services to continue through disruption?

Don’t misunderstand me.

Recovery will always matter.

There will always be circumstances where a system cannot maintain every function, where physical damage overwhelms available resources, or where restoring operations becomes the only practical option.

But I believe our ambitions should extend beyond simply restoring operations after failure.

We should be asking how to preserve essential services during the failure itself.

How to isolate faults before they spread.

How to establish independent operating capabilities.

How to maintain human readiness.

How to validate continuity across organizational and technological boundaries.

And how to modernize existing infrastructure while fundamentally improving the assumptions behind future designs.

This is the thinking behind a principle I’ve returned to repeatedly:

Failure and disaster are inevitable. Downtime isn’t.

That isn’t a promise that every system can achieve absolute zero downtime under every conceivable circumstance.

It’s an engineering challenge.

A demand that we stop accepting preventable interruption as an unavoidable consequence of complexity.

A reason to establish explicit operating limits, test our assumptions, and continually improve our ability to sustain essential functions.

Because the digital economy has already changed what society expects from infrastructure.

The question is whether our approach to resilience has kept pace.

We’ve built extraordinary technology.

We’ve connected systems across continents.

We’ve created capabilities previous generations could barely imagine.

But have we engineered the entire ecosystem to remain functional when things go wrong?

Or have we simply built increasingly sophisticated ways for everything to fail together?

Maybe it’s time we stopped measuring resilience primarily by how long we’ve gone without a problem and started measuring it by how well we can continue operating when one occurs.

And perhaps it’s time we stopped expecting individual industries to solve interconnected problems on their own.

Because if our infrastructure is interconnected, our responsibility for its resilience must be interconnected too.

That’s the conversation I want to have.

Not just with data center operators or network engineers, but with utility professionals, healthcare leaders, emergency responders, cybersecurity specialists, policymakers, and the people responsible for keeping essential services running every day.

I don’t believe any one organization, industry, or framework has all the answers.

But I do believe we’re asking too many of these questions independently.

And I’d genuinely like to hear from the people confronting these challenges firsthand.

Where do you see the greatest disconnect between the way we measure infrastructure reliability and the way we actually experience operational continuity?

John Klein
Founder & CEO, Atlas Global
Contributor, Outside the Rack. Inside the WAN.

Sources and Further Reading

• International Energy Agency, Key Questions on Energy and AI, 2026: https://www.iea.org/reports/key-questions-on-energy-and-ai/executive-summary
• Lawrence Berkeley National Laboratory, United States Data Center Energy Usage Report: 2025 Update, June 2026: https://bies.lbl.gov/publications/united-states-data-center-energy-2025
• U.S. Department of Energy, National Transmission Needs Study: https://www.energy.gov/oe/national-transmission-needs-study
• Uptime Institute, Tier Classification System: https://uptimeinstitute.com/tiers
• NIST, SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems: https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final
• U.S. Department of Health and Human Services, Summary of the HIPAA Security Rule: https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html
• NIST, SP 800-66 Rev. 2, Implementing the HIPAA Security Rule: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-66r2.pdf