High Availability

Definition

In enterprise and business architecture, High Availability (HA) refers to the degree to which a business capability, application, or infrastructure component remains operational and accessible over a defined period, typically expressed as a target uptime percentage (e.g., 99.9%, 99.99%) or as a maximum tolerable downtime. While HA originated as an infrastructure and systems engineering concern, business architects treat it as a non-functional requirement that must be traced back to the business capabilities and value streams it protects — not simply as an IT specification bolted onto a solution. HA sits alongside disaster recovery (DR), fault tolerance, and business continuity as related but distinct disciplines. HA is about minimizing planned and unplanned downtime during normal operations (redundant servers, failover clusters, load balancing); DR is about recovering after a catastrophic event; business continuity is the broader organizational capability to keep operating — including people, facilities, and processes — when disruption occurs. A capability can have a stringent HA requirement (near-zero downtime) and still need a separate DR strategy for scenarios HA design doesn't cover, such as regional outages or data corruption. Critically, HA requirements should not be set uniformly across the enterprise. Business architects work with capability owners to differentiate HA targets based on the criticality of the capability to core value streams — a real-time payment authorization capability warrants a far higher HA target than an internal reporting dashboard. Setting HA levels without this business-capability lens is one of the most common sources of architectural waste.

Origin & Context

The term emerged from systems engineering and IT operations in the 1990s, formalized through availability metrics like the well-known 'nines' scale (99.9%, 99.99%, 99.999%) used in service level agreements. As enterprise architecture matured through frameworks like TOGAF and the Business Architecture Guild's BIZBOK, HA was pulled into the business architecture conversation as part of capability-based planning — specifically, the practice of assessing capabilities not just for functional maturity but for the non-functional qualities (availability, scalability, security) that determine whether they can reliably support the business.

Why It Matters

CIOs and business architects care about HA because over-engineering it wastes capital on redundant infrastructure for low-criticality capabilities, while under-engineering it exposes revenue-generating or regulated capabilities to costly outages, customer attrition, and compliance breaches. Getting HA targets right — capability by capability — is a direct lever for cost optimization and risk management, and it's a recurring point of tension between finance (which wants to control infrastructure spend) and operations (which wants zero downtime everywhere). Business architects add value here by translating business criticality into differentiated HA tiers that IT can actually cost and design against, rather than leaving every system owner to negotiate availability targets in isolation.

Common Misconceptions

Myth: High Availability and Disaster Recovery are the same thing.

Reality: HA addresses continuous operation during normal conditions through redundancy and failover; DR addresses recovery after a major disruption like a regional outage or ransomware event. A well-architected capability typically needs both, but they are designed, tested, and funded separately.

Myth: Every critical system should have the highest possible HA rating.

Reality: HA targets should be tiered to the business criticality of the capability they support, as determined through capability heat mapping. Applying maximum HA uniformly drives unnecessary infrastructure cost without a corresponding reduction in business risk.

Myth: High Availability is purely an infrastructure and IT operations concern.

Reality: HA requirements originate from the business — specifically from value stream and capability criticality analysis. Business architects are responsible for surfacing which capabilities truly require high availability before IT designs the solution, preventing both over-investment and dangerous gaps.

Practical Example

A regional bank's business architecture team was asked to support a technology investment review after several near-miss outages in digital channels. Rather than accepting IT's request to upgrade infrastructure uniformly, the lead business architect facilitated a capability heat mapping session with line-of-business owners, scoring each capability on business criticality and current risk exposure. The exercise revealed that the Payment Processing and Customer Authentication capabilities were significantly under-resourced relative to their criticality, while an internal Reporting capability had HA investment far exceeding its actual business need. The architect used this cross-mapping to build a business case that reallocated infrastructure investment toward the capabilities that actually warranted near-continuous availability, and recommended relaxing the target for lower-criticality capabilities. The CIO used the capability-based justification to secure budget approval from the executive committee, since the request was now framed around business risk rather than a generic IT infrastructure ask.

Industry Applications

Financial Services

Payment processing, trading platforms, and core banking capabilities typically demand the highest HA tiers due to regulatory expectations and direct revenue impact of downtime.

Healthcare

Capabilities supporting clinical decision support and patient record access require high availability targets tied directly to patient safety, distinct from administrative capabilities with lower criticality.

Retail & E-commerce

Checkout and order management capabilities are prioritized for high availability during peak demand periods, while back-office capabilities like vendor onboarding tolerate lower availability targets.