fbpx
skip to Main Content

Tiered SAP System Landscape Overview

Companies that run SAP usually build what is commonly referred to as a tiered SAP System Landscape (or SAP Landscape). Generally, such SAP Landscapes encompass all the system types they have deployed (e.g. S4, ERP, BW, CRM, SCM and so forth). The term describes a way of organizing servers running SAP into different tiers that are defined by how the system is used: Most commonly, one for Development, one for Quality Assurance (QA) and one for Production.  This architecture for the SAP Landscape is determined early on depending on the specific business needs. The main purpose of the tiered SAP Landscape is to keep untested code, configuration and developments out of production until it is ready.

Understanding a Tiered System Landscape in SAP

What is a tiered SAP System Landscape? It contains all installed SAP components, usually comprised of several systems linked by transport routes for a given SAP system. For each application, there’s a system landscape, e.g. the S/4 Landscape, the BW Landscape and so forth.

Within each system landscape, development work is saved in workbench or a customizing request within the Development Tier – otherwise referred to as a “transport” and later is moved to QA for testing then finally into Production. The common scenario we described involves setting up three SAP systems, a so-called “Three Tier SAP Landscape,” which includes:

  • DEV – for development of custom-coded SAP elements and customization of SAP applications. Here, SAP consultants customize the application based on requirements in the change request. The Dev system in the landscape contains the customizing client, CUST. Dev may have a number of different clients, e.g. 100 – Master Config, 110 Development Test, 120 Sandbox.
  • QAS – for Quality Assurance. This is where core team members and others test the change request. It also may contain clients for Integration Testing, User acceptance Testing and Training.
  • PRD – for production systems, where the company’s live data lives. It may consist of Production or PROD client. It is completely separate from DEV and QAS.

There are variations on this basic three-tiered system landscape.  The development system can contain a client that is used for testing. It can also contain a client for Sandbox, or testing. The Sandbox client usually resides on the Development (DEV) tier, and the training client usually resides in the QAS system.

Two- and One-Tier System Landscapes

Not all system landscapes have three tiers. Some have two, or even just one. The two-tiered SAP System Landscape offers an alternative for organizations with smaller SAP implementations. They may not have the same kind of needs for extensive Workbench development. Typically, a two-system landscape consists of Dev and Production tiers. Here, QA is done on the Dev systems while the production version of the system is totally separate.

A two-tiered system SAP landscape can have several drawbacks that you should be aware of. Cross-client data is usually used in the Customizing and quality assurance clients. Changes in cross-client data in the Customizing client can affect tests in done on the QA client. The best practice is to implement strong change control procedures around Workbench changes. And, it’s helpful to maintain awareness and keep them as closely aligned to PRD as possible.

The one-tier landscape has everything on one server system and is not a setup that we recommend (unless an ancillary SAP product like basic Solution Manager is used). This landscape setup lacks a testing platform for patching, which increases the risk of something going wrong in Production. It also doesn’t allow testing of Workbench changes prior to hitting production. Finally, it can lead to backdoor methods of copying from one client to another, which can impact effectiveness of change control.

What is the Sandbox System in SAP?

The landscape should align with the lifecycle of your various SAP systems. A change request needs to flow from Dev to QAS to PRD. It’s a good practice to use a master Customizing client to make changes to Customizing data and Repository objects. Then, as change requests are released, they move to the QAS client. There, in addition to overall quality testing (i.e. functional testing) it’s possible to test if the transports are complete. Testing can also detect if linked changes are missing. From there, the change request moves to Production.

SAP Production System

The SAP System Landscape Production tier (for example: S/4HANA Production) is the live system for business usage. It’s the system of record for that particular functionality and other core systems needed to operate the business. This is where private, sensitive data resides. Production Tiers within SAP Landscapes are where security and compliance controls have to be in full effect. From a compliance standpoint, it’s the production system that gets audited.

Running More than a Three-Tier System SAP Landscape

Some organizations prefer to build landscapes with more than three tiers.  They might place the Sandbox or training systems into separate tiers. Or, they may build a specialized pre-production server for staging. They might separate unit testing and quality testing into different tiers.

There are many reasons for taking this expansionist approach. If activity is intense in one area, like training or quality testing, it may do better in isolation. For example, if there are hundreds of people being trained on a system that also has to support testing, then one or both of these workloads is going to slow down. In certain testing scenarios, the ability to measure application performance in isolation is crucial to getting accurate results. This could be a strong argument for utilizing a separate system.

The drawback to a four- or five-system SAP landscape is complexity and cost. More tiers for more systems translates into more servers and more administrative overhead, which can get expensive and complicated to manage. With SAP in a cloud platform this can become simpler, with many companies offering creative alternatives. For example, a smaller business with minimal change may choose to put their Development and Test Tiers into an “on demand” cloud platform like the public cloud – meaning it only incurs costs when it’s switched on.

Do Smaller Organizations Need a Three-Tier SAP System Landscape?

Not every company needs a three-tier landscape. Certainly, a large enterprise with extensive customization needs is best-served by a three-system landscape. Small- to medium-sized enterprises (SMEs) might manage fine with a two-system landscape. Alternatively, they could choose to work with cloud-based systems for the DEV and QAS components of their landscapes to minimize infrastructure expenses. This approach can be a good compromise as it gives them the flexibility and separation of environments that works best, while providing cost savings versus implementing a three-system landscape.  Working with a partner like Symmetry can provide the guidance and implementation services your organization needs for your SAP System Landscapes.

Steve Lofthouse, Solutions Architect

Steve Lofthouse is a Solutions Architect on Symmetry’s EMEA team bringing 14 years of SAP cloud and managed service experience. He’s dealt with solutions coming from multiple perspectives in his experience including but not limited to: pre-sales, technical consultant, support and end user. With this experience, Steve is able to deliver all required components needed for almost any situation with a sound understanding, resulting in effective managed cloud environments for various enterprise solutions.