System Landscape Design, Instance Distribution, and High Availability Planning
Explains how individual SAP systems are combined into a landscape (DEV/QAS/PRD), how instances are distributed across hosts for scalability, and the architectural patterns used to achieve high availability and disaster recovery.
Explanation
Once a Basis consultant understands a single SAP system's three-tier structure, the next level of architectural thinking is the landscape: how multiple SAP systems relate to each other across the software lifecycle, and how a single system's components are physically or virtually distributed to meet performance, availability, and recovery requirements. A typical landscape includes at minimum a Development (DEV) system, a Quality Assurance (QAS) system, and a Production (PRD) system, connected by a transport route so that configuration and custom code changes flow in a controlled sequence: DEV to QAS to PRD. This is not just a convenience; it is a governance control that prevents untested changes from reaching production and creates an audit trail of what was moved, when, and by whom. In more complex landscapes, especially for S/4HANA implementations with parallel workstreams, you may see additional systems such as a sandbox for early prototyping, a training system, or a pre-production system that mirrors PRD configuration for final validation before major changes (upgrades, support packs) are applied. Within a single system, instance distribution becomes important as load grows. A small system might run ASCS and one application server instance on a single host. A larger production system typically separates the database server, the ASCS/SCS instance, and multiple application server instances across different hosts, allowing horizontal scaling: if dialog load increases, you add another application server instance rather than trying to make one server bigger indefinitely. The message server (part of ASCS) performs logical load balancing by directing new user logons to the application server instance with the most available capacity, based on load information each instance reports back periodically. High availability (HA) planning addresses the single points of failure inherent in this architecture. The database and the ASCS/SCS instance (with its enqueue server holding the lock table) are the two classic single points of failure in a traditional SAP landscape, because losing either one stops the entire system, not just one component. Common HA patterns include clustering the ASCS instance so that if the host fails, another node takes over the same virtual hostname and IP, and using database-level HA features (such as replication or clustering technologies appropriate to the underlying database platform) to protect the database tier. For S/4HANA specifically, HANA System Replication is commonly used to maintain a synchronized standby database that can take over with minimal data loss if the primary fails; the exact replication mode (synchronous or asynchronous) is a trade-off between data loss tolerance (RPO) and performance impact on the primary. Disaster recovery (DR) is a related but distinct concern from HA: HA typically protects against a single host or component failure within a data center, while DR protects against loss of an entire data center or region, usually involving a secondary site with its own copy of the ASCS and database components, kept in sync through replication technologies and activated through a documented failover procedure. In cloud contexts (public cloud S/4HANA or BTP-hosted extensions), some of this HA/DR infrastructure is managed by SAP or the hyperscaler under the service model, and the customer's architectural responsibility shifts toward configuring failover behavior for their extensions and understanding the provider's stated recovery objectives rather than building the underlying clustering themselves; consultants should not assume on-premise HA patterns apply unchanged to a public cloud subscription without verifying the specific service's documented architecture. A Basis consultant working on landscape design must balance these architectural decisions against cost, complexity, and actual business requirements for uptime, since over-engineering HA/DR for a non-critical system wastes budget just as under-engineering it for a revenue-critical system creates unacceptable risk.
Real project scenario
A retail company running S/4HANA on-premise experienced a database host failure during peak sales season that caused a full production outage lasting several hours because HANA System Replication had been configured but never tested end-to-end after a recent infrastructure change. The postmortem led to a redesigned DR runbook, a quarterly failover test schedule, and a decision to move the ASCS instance onto a properly clustered pair of hosts, since it had previously been running unprotected on a single host as a historical oversight from the original ECC-to-S/4HANA migration project.
Common mistakes
• Assuming a documented HA/DR architecture is actually working without periodically testing real failover, not just configuration checks. • Leaving the ASCS/SCS instance unprotected while focusing all HA investment on the database tier, ignoring that ASCS failure also stops the entire system. • Confusing high availability (protection against component failure) with disaster recovery (protection against site/region loss) and designing only for one when the business needs both. • Designing the same landscape topology for a low-criticality sandbox system as for production, wasting budget and operational effort. • Assuming public cloud S/4HANA offerings provide the exact same customer-managed HA/DR controls as an on-premise deployment, without checking the specific service's documented recovery capabilities.
Best practices
• Maintain a landscape diagram showing all systems (DEV/QAS/PRD and any additional tiers) with their transport routes clearly documented and kept current. • Protect both the database tier and the ASCS/SCS instance with appropriate HA mechanisms; do not treat enqueue protection as optional in production. • Schedule and execute regular failover tests for HA and DR configurations rather than relying on initial setup validation alone. • Size HA/DR investment to match documented business RTO/RPO requirements rather than applying a uniform standard to every system in the landscape. • For cloud-hosted or subscription SAP services, explicitly verify the provider's stated HA/DR model instead of assuming on-premise patterns transfer directly.
Interview angle
Interviewers often probe whether a candidate can distinguish high availability from disaster recovery, and whether they understand why ASCS/enqueue and the database are the two classic single points of failure in a traditional SAP landscape. Strong candidates also acknowledge that responsibility for HA/DR infrastructure shifts in cloud/subscription models and avoid overstating what a customer directly controls in a public cloud deployment.