Mission-Critical Enterprise Systems... What's a Mission? And What's Critical?: Processor and technology requirements for enterprise computing

The banking, insurance, healthcare, and transportation systems everyone depends on but never sees run on enterprise machines — IBM mainframes and Power Systems — engineered for a level of reliability far beyond ordinary computers, on the order of 99.999999 percent uptime; this ASPLOS 2026 keynote (IBM — Hillery C. Hunter) looks inside how silicon, microarchitecture, and system design combine to reach that "eight nines" of resiliency, and how new AI workloads like in-transaction fraud detection and AI-driven operations are reshaping what enterprise computing must deliver.

The argument in one glance

Problem

The systems that run critical industries must almost never fail

Most of the computers people think about are the ones they touch — phones, laptops, the cloud services behind websites. But behind the scenes there is another class of machine that quietly runs the world's critical industries: enterprise systems, such as IBM mainframes (IBM Z) and IBM Power Systems, that fuel banking, manufacturing, healthcare, insurance, and transportation. These are the systems you never see but always rely on: when a payment clears, an insurance claim is processed, or a hospital record is retrieved, an enterprise system is doing the work. What sets these systems apart is not raw speed but a requirement that is almost alien to consumer computing — they must essentially never go down. The bar is extraordinary: on the order of "eight nines" of system-level resiliency, meaning 99.999999 percent uptime. That is a few hundred milliseconds of downtime per year. Ordinary systems aim for perhaps three to five nines and accept that failures happen and get retried; enterprise systems are held to a standard where a failure that loses a transaction or corrupts a record is unacceptable, because the consequences — financial, legal, safety — are severe. Delivering that level of reliability, on real silicon running real workloads, is a distinct and formidable engineering problem, and it is only getting harder as the workloads change.
What people did

Assume commodity, scale-out reliability is enough

The dominant modern approach to reliability is to build it out of unreliable, commodity parts: run many cheap machines, replicate data across them, detect failures, and retry or fail over to another node. This is how large-scale cloud services achieve high availability — the individual components are expected to fail, and the system as a whole tolerates it through redundancy and software recovery. It is cost-effective and scales, and for many workloads it is exactly right.
Why it fell short

Retry-and-replicate is not the same as never losing a transaction

Commodity scale-out delivers availability, but the enterprise requirement is subtler and stricter. For a mission-critical transaction — moving money, committing a medical record — it is not enough that the service stays up on average; the individual operation must complete correctly, exactly once, with its integrity intact, even in the presence of hardware faults, and often within a tight latency bound and under strict regulatory constraints. A retry-and-replicate design can drop or duplicate work at the boundaries, and reasoning about correctness across a loosely-coupled fleet is hard. Enterprise systems instead pursue resiliency vertically and deeply: reliability is engineered into the silicon technology, the processor microarchitecture, and the surrounding system elements together, so that faults are detected and recovered from transparently, without losing the transaction and often without the workload even noticing. This is a different philosophy — build each layer to be trustworthy and to catch and correct errors, rather than assume each layer fails and paper over it above. And the challenge is intensifying, because a new class of workload is arriving that these systems were not originally built for: artificial intelligence, which the enterprise now wants to run directly on its most critical systems.
This paper's idea

Engineer resiliency from silicon to system, and absorb AI as a first-class workload

This keynote looks inside enterprise systems to show how their extreme resiliency is actually built and how it is being reshaped by AI. The thesis is that "eight nines" of system-level resiliency is not a single feature but an emergent property of many layers designed to work together: the silicon technology, the microarchitecture, and the system elements are co-engineered so that errors are caught and corrected at every level and faults are recovered transparently, keeping the machine and its transactions running. The talk explores what a "mission" and "critical" actually mean in this setting — which business functions cannot be allowed to fail, and why. It then turns to how the workloads on these systems are changing. New drivers are pushing AI directly into enterprise computing: AI for fraud detection (scoring transactions in real time as they happen), AI for insurance claims processing, and AI-driven system operations (using machine learning to run and manage the systems themselves). These change enterprise requirements, because the machines must now deliver AI inference — at scale, on the transaction path, under latency limits — without compromising the resiliency and integrity guarantees that are the whole point of an enterprise system. The keynote discusses the processor and technology requirements that follow: how enterprise silicon and systems must evolve to make AI a first-class, trustworthy part of mission-critical computing rather than a separate, best-effort add-on.

Why this problem is worth solving

The invisible enterprise backbone underpins the functioning of society’s critical systems, so its reliability is not a technical nicety but a societal dependency.

The systems that clear payments, adjudicate insurance claims, manage patient records, and route logistics are the ones whose failure is least tolerable, precisely because so much depends on them and because the failures are consequential — money lost, care delayed, trust broken. Unlike a consumer app, where an occasional crash is an annoyance, an enterprise system that loses a financial transaction or corrupts a record creates real-world harm and legal exposure. That is why these systems are held to a reliability standard — around eight nines of uptime — that is orders of magnitude stricter than typical computing, and why the engineering behind them is worth understanding even though most computer scientists never touch it directly. As more of the economy runs on digital transactions, and as those transactions become more automated and higher-volume, the value of infrastructure that can be trusted to essentially never fail only grows. Understanding how such resiliency is achieved, and what it now takes to add new capabilities to these systems without eroding it, is important for anyone thinking about where computing that truly cannot fail is headed.

The central tension is adding a demanding new workload to a system whose defining property is that it must not be disturbed.

Enterprise systems achieve their resiliency through decades of deep, vertical engineering that assumes tight control over what the machine does and how it behaves under fault. Artificial intelligence is a very different kind of workload from the transaction processing these systems were built around: it is compute-intensive, it wants specialized acceleration, and the places it is most valuable — scoring a transaction for fraud in real time, as part of the transaction itself — put it directly on the critical path where latency and integrity matter most. The obvious way to do AI, offloading it to a separate best-effort cluster, is exactly what you cannot do if the AI decision must be part of a mission-critical transaction that cannot wait and cannot fail. So the requirement becomes to bring AI inference inside the resilient system, at the speed and with the guarantees the transaction demands, which forces changes in the processor and the surrounding technology — how acceleration is integrated, how it meets latency bounds in-transaction, and how it inherits rather than undermines the system’s reliability. This is the frontier the keynote frames: not AI as a separate product, but AI as a new, first-class requirement reshaping what enterprise silicon and systems must provide.

What people did before, and where it broke

Aim for a few nines and accept failures. Design consumer and many cloud systems to tolerate occasional downtime and retry. Where it broke. For mission-critical transactions, losing or duplicating even one operation is unacceptable, so a few nines is far short of the requirement.
Build reliability from unreliable commodity parts. Replicate across cheap machines and recover in software. Where it broke. It delivers average availability but not per-transaction integrity, exactly-once completion, and tight latency under fault that critical operations demand.
Treat AI as a separate, best-effort service. Offload machine-learning inference to a distinct cluster. Where it broke. When the AI decision must be part of a mission-critical transaction (real-time fraud scoring), it cannot be shipped off the critical path without breaking latency and integrity.
Bolt new workloads onto the system without re-examining requirements. Add AI as an afterthought to enterprise machines. Where it broke. AI’s compute and acceleration needs, on the transaction path, change what the processor and technology must provide if resiliency is to be preserved.
The gap. No approach delivered eight-nines resiliency and, at the same time, made AI a first-class, in-transaction capability without compromising that resiliency.

What the keynote covers

From how enterprise resiliency is built to how AI reshapes it

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Build reliability into every layer rather than assuming each layer fails. The enterprise philosophy is to engineer trustworthiness from the silicon up through the system so faults are caught and corrected transparently, keeping transactions intact. Improving a system’s robustness by hardening its layers to detect and recover from faults, rather than tolerating failure only at the top, is the same concern the work on improving the robustness of a DPU-enhanced platform (Fault-Escaping) covered elsewhere on this site addresses, engineering resilience into the platform itself. The keynote presents this vertical, silicon-to-system resiliency as the defining property of mission-critical enterprise machines.

Bring AI into running the systems, not just the applications. One of the keynote’s new drivers is AI-driven system operations — using machine learning to manage and operate the enterprise systems themselves. Applying machine learning to the operation and management of computing systems, so that the infrastructure becomes learning-assisted rather than purely hand-run, is exactly the trajectory the work on whether machine learning for systems has reached an inflection point covered elsewhere on this site surveys, arguing that learned policies are moving into systems management. The keynote positions this as one of the forces changing what enterprise computing must support.

Deliver AI inference on the critical path, under strict latency. AI for real-time fraud detection means scoring a transaction as it happens, so inference must meet the transaction’s latency and throughput demands rather than run as a separate offline batch. Serving machine-learning inference under low-latency, high-throughput constraints, as a first-class part of a live request path, is the same problem the work on a native serverless system for low-latency, high-throughput inference (INFless) covered elsewhere on this site addresses, treating inference latency as a first-order requirement. The keynote frames in-transaction AI as a driver forcing enterprise processors and systems to meet exactly these constraints while preserving resiliency.

A closer look at eight-nines resiliency

What it takes to almost never lose a transaction

An illustrative framing of how enterprise resiliency is built (this explainer is written from the keynote's abstract plus general public background; the talk's specific content is in the paper).

Step 1 of 5

Set an extraordinary reliability target

The enterprise bar is around eight nines of system-level uptime — 99.999999 percent — which is roughly a few hundred milliseconds of downtime per year, far stricter than the three-to-five nines typical systems aim for.

A single lost or corrupted mission-critical transaction is unacceptable.

Why it works

Vertical engineering meets a bar horizontal recovery cannot. Retry-and-replicate delivers availability but can lose per-transaction integrity → but building each layer to catch and correct faults → so mission-critical operations complete correctly even under hardware faults.
Transparent recovery keeps the workload running. A fault could otherwise stop or corrupt a transaction → but detecting and recovering from it across silicon, microarchitecture, and system elements → so the machine keeps running and the transaction is not lost.
Defining the mission focuses the effort. Not every operation needs eight nines → but identifying which functions are truly critical and why → so the extraordinary engineering is spent where failure is genuinely unacceptable.
In-transaction AI must inherit the guarantees, not bypass them. Offloading AI to a best-effort cluster breaks latency and integrity → but delivering inference inside the resilient system on the transaction path → so real-time fraud scoring can be both fast and trustworthy.
New drivers reshape the requirements, not just the applications. Treating AI as a bolt-on would strain the system → but re-examining processor and technology requirements for AI as first-class → so enterprise systems evolve to support it without eroding resiliency.

What it costs (open questions and caveats)

This is a keynote, not a technical results paper. It frames the landscape of enterprise resiliency and the arrival of AI, and discusses requirements and directions rather than presenting a single artifact with a controlled evaluation, so its contribution is perspective and framing.
Extreme resiliency has real cost. Engineering eight nines through deep vertical redundancy and error correction is expensive in silicon area, design effort, and price, which is why it is reserved for genuinely mission-critical workloads rather than applied everywhere.
In-transaction AI raises hard integration questions. Bringing inference onto the critical path under latency limits while preserving resiliency is a genuine challenge the talk raises; how enterprise silicon and systems should evolve to meet it is a direction, not a solved problem.
The requirements are specific to the enterprise setting. The philosophy of per-transaction integrity and eight-nines uptime is tailored to critical industries; it is not the right or affordable target for most consumer or best-effort cloud workloads.
This explainer is written from the abstract and general background. The specific data, examples, and arguments of the talk itself are not reproduced here; the background on nines of availability and resiliency engineering is standard public knowledge provided for context, not a claim about the talk’s exact content.

The framing, at a glance

Reliability philosophies for computing systems

Property	Consumer / best-effort	Commodity scale-out cloud	Mission-critical enterprise
Reliability target
How reliability is achieved
Per-transaction integrity
AI on the critical path
Where it fits

The keynote's framing of reliability philosophies. Mission-critical enterprise systems (IBM Z, IBM Power) pursue around eight nines of resiliency through vertical silicon-to-system engineering that guarantees per-transaction integrity, and now must deliver AI — real-time fraud detection, claims processing, AI-driven operations — as a first-class, in-transaction capability without compromising that resiliency. This explainer is written from the keynote's abstract plus general background; the talk's specific content should be read from the paper.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

This explainer is written from the keynote’s abstract (and general, public background about enterprise systems); the full text or slides of the talk were not accessible at the time of writing. It is an invited keynote by Hillery C. Hunter of IBM, not a technical results paper. Per the abstract, the talk looks inside enterprise systems — mainframes (IBM Z) and IBM Power Systems — that fuel banking, manufacturing, healthcare, insurance, transportation, and other critical industries; discusses the silicon technology, microarchitecture, and system elements that combine to deliver eight nines of system-level resiliency (99.999999 percent uptime); and explores how changing workloads and new drivers — AI for fraud detection, AI for insurance claims processing, and AI-driven system operations — are changing enterprise requirements. The framing of consumer versus scale-out versus enterprise reliability, the description of how eight-nines resiliency is engineered vertically, the roughly-few-hundred-milliseconds-per-year interpretation of eight nines, and the discussion of in-transaction AI above are provided as standard public context to make the talk’s subject intuitive; they are not verbatim claims from the talk, whose specific data, examples, and arguments are not reproduced here. The step-by-step walkthrough is an illustrative framing, not a description of the talk’s exact content. The talk’s own presentation should be consulted for its specific claims.

Background

Why the most critical computing is the computing you never see

It helps to see this keynote within a broad pattern: the computing that matters most to the functioning of society is often the least visible and the least discussed in research, precisely because its job is to run flawlessly and unnoticed. Consumer devices and web-scale clouds get the attention, but underneath the economy sits a layer of enterprise infrastructure engineered to a standard of reliability that most of computing never attempts — where the goal is not to be fast or cheap but to essentially never fail, and to never lose a transaction that moves money or records a life event. That reliability is not free or automatic; it is the product of deep, deliberate engineering across silicon, microarchitecture, and system, aimed squarely at correctness and continuity under fault. What makes the moment interesting is that this most conservative, most reliability-obsessed corner of computing is now being asked to absorb the least predictable, fastest-moving workload of the era — artificial intelligence — and to do so on the critical path without giving up any of its guarantees. This concern for keeping the infrastructure everyone depends on trustworthy and well-designed as its demands evolve is the same terrain the work on a holistic framework for designing carbon-aware datacenters (Carbon Explorer) covered elsewhere on this site occupies, thinking rigorously about the invisible infrastructure that underpins everything else. The keynote’s contribution is to bring the requirements of mission-critical enterprise computing — resiliency first, now with AI as a first-class demand — into the architecture community’s view, and to ask what processor and technology directions follow.

If you remember only three things

1. Enterprise systems — IBM mainframes (IBM Z) and IBM Power Systems — are the invisible backbone of critical industries like banking, insurance, healthcare, and transportation: systems you never see but always rely on. What defines them is not speed but reliability, held to a standard of around eight nines of system-level resiliency (99.999999 percent uptime, a few hundred milliseconds of downtime per year), far stricter than the few nines consumer and typical cloud systems accept. This matters because for mission-critical transactions — moving money, recording a medical event — losing or corrupting even one operation is unacceptable, with severe financial, legal, and safety consequences.
2. That resiliency is not a single feature but an emergent property engineered across layers: the keynote looks at how silicon technology, processor microarchitecture, and system elements are co-designed so faults are detected and recovered transparently, keeping transactions intact rather than tolerating failure and retrying above. This is a different philosophy from commodity scale-out, which builds availability from unreliable parts and software recovery — good for average uptime but not for the exactly-once, integrity-preserving, low-latency completion mission-critical operations require. The talk also asks what "mission" and "critical" actually mean, focusing the extraordinary engineering on the functions that genuinely cannot fail.
3. The keynote then argues that AI is reshaping enterprise requirements. New drivers — AI for real-time fraud detection (scoring transactions as they happen), AI for insurance claims processing, and AI-driven system operations (machine learning running the systems themselves) — push AI directly onto the critical path of resilient systems. Because in-transaction AI cannot be offloaded to a separate best-effort cluster without breaking latency and integrity, enterprise silicon and systems must evolve to deliver inference at scale, on the transaction path, without compromising resiliency — making AI a first-class, trustworthy part of mission-critical computing rather than a bolt-on. This is a keynote framing the landscape; this explainer is based on its abstract and public background.

Check yourself

Check your understanding

1. What distinguishes mission-critical enterprise systems like IBM Z from ordinary consumer or cloud systems?
2. Why is commodity scale-out reliability (replicate across cheap machines and retry) not sufficient for mission-critical enterprise workloads?
3. According to the keynote's framing, how is "eight nines" of system-level resiliency achieved?
4. How is AI changing the requirements for enterprise systems, per the keynote?

Sources

The paper is “Mission-Critical Enterprise Systems… What’s a Mission? And What’s Critical?: Processor and technology requirements for enterprise computing,” an invited keynote by Hillery C. Hunter (IBM; General Manager for IBM Power and IBM Infrastructure Chief Technology Officer) at ASPLOS 2026, DOI 10.1145/3779212.3795613. It is open access under CC BY-NC-ND.

This explainer is written from the keynote’s abstract; the full text or slides of the talk were not accessible at the time of writing. Per the abstract, the keynote looks inside enterprise systems — mainframes (IBM Z) and IBM Power Systems — that fuel banking, manufacturing, healthcare, insurance, transportation, and other critical industries; discusses the silicon technology, microarchitecture, and system elements that combine to deliver eight nines of system-level resiliency (99.999999 percent uptime); and explores how changing workloads and new drivers — AI for fraud detection, AI for insurance claims processing, and AI-driven system operations — are changing enterprise requirements, including the processor and technology requirements that follow. The framing of reliability philosophies, the description of vertically-engineered resiliency, and the discussion of in-transaction AI in this explainer are provided as standard public background to make the talk’s subject intuitive, and are not verbatim claims from the talk. The talk’s own presentation should be consulted for its specific data, examples, and arguments.