SAP classic enterprise architecture: landscapes, transports, and deployment patterns | KMS ITC | KMS ITC - Your Trusted IT Consulting Partner
KMS ITC
Enterprise Architecture 12 min read

SAP classic enterprise architecture: landscapes, transports, and deployment patterns

SAP’s ‘classic’ model still underpins many S/4HANA programs: a three-tier landscape (DEV/TEST/PRD), controlled change promotion, and resilient central services. This guide explains the patterns that keep SAP environments stable at scale.

KI

KMS ITC

#sap #s4hana #enterprise-architecture #basis #devops #deployment #change-management #high-availability

Executive summary

SAP environments that run reliably for years tend to share a small set of “classic” architecture decisions:

  • A landscape that separates build, validation, and production operations (typically DEV → TEST/QAS → PRD) so change can be promoted safely.
  • A change promotion mechanism (transports and release governance) that makes system state reproducible.
  • A deployment topology that explicitly treats central services, application servers, and database as distinct tiers, each with their own availability and scaling patterns.
  • A controlled web entry layer (often a reverse proxy / web switch) that protects application servers and gives consistent routing.

These patterns remain relevant whether the platform is on-prem, hosted, or cloud—because they are ultimately about risk management, auditability, and operational resilience.

What changed

Two trends have made “classic SAP architecture” newly important for enterprise architects (even in 2026):

  1. SAP landscapes are becoming more hybrid by default. Many organisations run mixed estates (legacy SAP ERP, S/4HANA, BW, PI/PO or replacements, and cloud extensions), which increases integration and change coordination complexity.

  2. Cloud hosting changes failure modes, not responsibility. Moving infrastructure to hyperscalers can improve underlying availability options, but it also makes it easier to accidentally over-trust “platform defaults” and under-invest in SAP-specific HA patterns (central services, enqueue, shared file systems, routing).

In short: the architecture still needs to be designed intentionally—especially around change control and availability boundaries.

Why it matters

1) The landscape is a governance control, not just an environment list

A three-system landscape is not an arbitrary tradition; it is a control system that allows:

  • Work to be performed with lower blast radius (DEV)
  • Realistic validation against representative configuration and data (TEST/QAS)
  • Stable operations and auditability (PRD)

In SAP S/4HANA Cloud, the three-system concept still exists (development, test, production), with explicit mechanisms for configuration distribution and transport orchestration across the landscape (SAP Press: three-system landscape).

2) SAP “deployment” is multi-layered: users, web entry, app tier, central services, database

A typical enterprise deployment separates concerns into layers:

  • User access (SAP GUI, browser/Fiori, APIs)
  • Web entry / reverse proxy (routing, TLS termination, request filtering)
  • Application servers (scale-out, stateless-ish processing)
  • Central services (message/enqueue and related shared services)
  • Database tier (HANA/ASE/etc., replication and backups)

This separation is what enables architects to apply the right pattern to each layer: scale-out where possible, failover where required, and governance everywhere.

3) High availability hinges on central services and enqueue semantics

For many SAP NetWeaver-based systems, central services are not optional plumbing; they are the coordination point for the application tier.

For example, AWS documentation explicitly calls out Pacemaker clustering for ABAP SAP Central Service (ASCS) and Enqueue Replication Server (ERS) across availability zones (AWS: ASCS/ERS Pacemaker).

Architecturally, this matters because:

  • Application servers can often be scaled horizontally.
  • Central services require careful failover design, because lock/enqueue behaviour is central to consistency.

4) The web entry layer is part of the security boundary

A common enterprise pattern is to keep application servers off the internet and terminate/route HTTP(S) through a dedicated entry component.

Microsoft’s SAP on Azure guidance for SAP Web Dispatcher describes it as the entry point for HTTP(S) requests into SAP and a reverse proxy, with both active/passive and active/active HA options (Microsoft: SAP Web Dispatcher HA on Azure).

Even if an organisation uses cloud-native load balancers, the key architecture decision remains the same:

  • define a consistent ingress pattern
  • centralise TLS policy and routing
  • keep the SAP application tier behind controlled boundaries

What to do (practical patterns and decisions)

Pattern A — “Classic” three-tier landscape (DEV → TEST → PRD)

Use when: auditability, controlled releases, and separation of duties matter.

Key decisions:

  • Treat landscape promotion as a product pipeline, not a manual activity.
  • Define “done” as transported + validated + monitored, not “developed”.
  • Standardise refresh strategies (e.g., selective data refresh into TEST) so testing is meaningful.

Pattern B — Split central services from application servers

Use when: scaling needs are non-trivial or availability requirements are strict.

Key decisions:

  • Run ASCS/ERS as a managed failover unit (clustered, tested).
  • Keep application servers stateless where possible (session handling and caching as explicit concerns).
  • Define shared filesystem and transport directory strategy explicitly (cloud file service, NFS, etc.).

Pattern C — Explicit ingress architecture (reverse proxy / web switch)

Use when: users, partners, or apps access SAP over HTTP(S).

Key decisions:

  • Choose the entry layer (Web Dispatcher, WAF/reverse proxy, or a combination).
  • Decide on active/passive vs active/active HA, and test failover with real client behaviour.
  • Centralise certificate lifecycle management and logging.

Pattern D — Design for operational runbooks, not just diagrams

Use when: you want the architecture to survive handover from project to operations.

Key decisions:

  • Define failure modes per tier (DB, central services, app servers, ingress) and document runbooks.
  • Regularly test “boring disasters”: node reboot, AZ loss (where applicable), cert expiry, DNS change, transport queue backlog.

Risks and trade-offs

  • Over-segmentation can slow delivery. More tiers and environments improve safety, but add process and cost. Mitigate by automating promotion and testing.

  • Cloud can hide architecture debt. It is easy to assume “multi-AZ” equals “HA”. In practice, SAP-specific HA requires deliberate configuration, clustering, and testing—especially around central services and shared storage.

  • Ingress decisions affect security posture. A poorly designed reverse proxy layer can become a single point of failure or a blind spot for logging and access control.

  • Transports can become a bottleneck. Without good governance, transport queues and sequencing errors create release friction. Treat transports as a pipeline with ownership, standards, and metrics.

Sources