Architecting HANA Landscapes: HA/DR, Multitenancy, and Lifecycle Governance (Part 4)

Architecting a HANA landscape is not just about picking a replication mode; it is about aligning technical resilience with business RTO/RPO targets, cost constraints, organizational skill maturity, and regulatory obligations, while ensuring the design remains operable by the Basis team over the system's multi-year lifecycle. This lesson focuses on the decisions an architect must make and defend, not the button-clicking steps already covered in earlier administration and monitoring lessons.

High availability and disaster recovery. For on-premise and private cloud S/4HANA, HANA System Replication (HSR) is the standard mechanism for both HA (within a site, synchronous) and DR (cross-site, typically asynchronous). Architects must decide: synchronous vs asynchronous replication mode based on network latency and RPO tolerance; number of secondary sites (one for HA, a second for DR is common in regulated industries); whether secondaries are usable for reporting/backup offload (read-enabled secondary) which adds value but also operational complexity; and failover automation via cluster managers versus manual, controlled failover. The trade-off is always: tighter RPO/RTO costs more in infrastructure, network bandwidth, and operational complexity, and increases the blast radius of misconfiguration. In public cloud and BTP-delivered HANA services, HA/DR topology, failover automation, and achievable RTO/RPO are largely defined by the provider's service tier; the architect's role shifts to selecting the right service tier, understanding contractual RTO/RPO commitments, and designing the application and integration layer to tolerate the platform's failover behavior rather than designing the replication mechanics directly.

Multitenancy strategy. Multiple-container HANA systems allow several tenant databases under one system database, useful for consolidating non-production systems or running logically separated tenants (e.g., one tenant per SAP application) while sharing system-level resources. The architectural trade-off is resource isolation versus consolidation efficiency: tenants share CPU and memory pools unless resource governance is deliberately configured, so a noisy-neighbor tenant can degrade others. Architects must decide tenant boundaries based on criticality separation (do not mix production and non-production tenants), patching cadence alignment (all tenants share the same HANA revision, so tenants needing different patch cycles cannot coexist), and backup/recovery granularity (tenant-level backup and recovery is supported, but system-level maintenance affects all tenants).

Sizing and capacity governance. Architects must establish a repeatable sizing methodology (using vendor sizing tools plus workload-specific growth projections) and a governance process for approving memory/CPU expansion requests, because ad hoc scaling driven by monitoring alerts (from the earlier monitoring lesson) without a sizing review leads to unpredictable cost and licensing exposure. Memory-based HANA licensing models make capacity decisions directly cost-relevant, so capacity governance is also a cost governance function.

Lifecycle and patch governance. Establish a documented patch/upgrade cadence (e.g., aligned to SAP maintenance windows) balancing security/stability against regression risk, and a test-then-promote pipeline through landscape tiers. For S/4HANA public cloud and BTP, the provider controls much of this cadence; the architect's governance role is to track announced maintenance windows, assess application-level impact, and ensure integration and custom extensions are validated against provider-driven changes.

Operability and knowledge governance. A landscape that is technically resilient but operationally fragile (undocumented failover procedures, single point-of-knowledge in one engineer, no rehearsed DR drills) is a real production risk. Architects should mandate periodic failover/recovery drills, maintain current runbooks, and ensure monitoring and alerting thresholds (from earlier lessons) are reviewed as the landscape evolves. Cross-deployment awareness matters: an architect designing a hybrid landscape (on-premise ECC feeding S/4HANA private cloud, integrated with BTP services) must document which failover and recovery responsibilities sit with the customer team versus the provider, and ensure end-to-end RTO/RPO is achievable across the whole chain, not just within one component.

A regulated financial services customer running S/4HANA private cloud requested a DR redesign after an audit finding flagged unclear RTO. The architect assessed the existing single-site HSR HA setup, proposed adding an asynchronous DR secondary in a second region, defined tenant boundaries so production and QA no longer shared a multi-container system, and established a quarterly failover drill with documented runbooks; the audit finding was closed after the first successful rehearsed failover with measured RTO within target.

• Choosing synchronous replication across high-latency links, degrading production performance to satisfy an unrealistic RPO target.
• Mixing production and non-production tenants in one multi-container system, exposing production to patching or resource contention risk from lower environments.
• Sizing decisions made reactively from alert thresholds rather than a documented capacity governance process, causing licensing cost surprises.
• Assuming public cloud/BTP HANA services provide the same replication control and RTO/RPO customization as on-premise HSR.
• Never rehearsing failover, so the first real failover happens uncontrolled during an actual outage.
• Failing to document end-to-end RTO/RPO across a hybrid landscape spanning on-premise, private cloud, and BTP components.

• Derive replication mode and topology from documented business RTO/RPO targets, not from technical maximalism.
• Separate production and non-production into different multi-container systems or standalone tenants.
• Establish a formal capacity/licensing governance process tied to sizing reviews, not reactive scaling.
• Document and rehearse failover/DR procedures on a regular cadence with measured outcomes.
• Clearly delineate customer versus provider responsibility for HA/DR and patch governance in hybrid or cloud-inclusive landscapes.
• Revisit HA/DR and multitenancy design whenever workload, criticality, or regulatory requirements change.

Architect interviews probe whether a candidate can justify HA/DR design choices against business RTO/RPO rather than defaulting to 'most resilient possible'; expect questions on synchronous vs asynchronous replication trade-offs, multitenancy isolation risks, how licensing models influence sizing governance, and how responsibilities shift when part of the landscape is provider-managed (public cloud/BTP) versus customer-managed.