Introduction
When you want to run your business processes productively on SAP systems based on ABAP Platform or its predecessor AS ABAP (such as SAP ECC or SAP S/4HANA Server), you need to have a multi-system landscape. But which landscape fits best to your needs? Is it recommended that you use a three-system landscape, a four-system landscape, or even a dual system landscape? Additionally, which factors have an influence on your decision? You will examine each of these questions in this lesson.
Before discussing the different landscape options with their pros and cons, let's go back one step and discuss the task of a system administrator in general: the general task (or goal) of a system administrator is to provide a stable, available, high-performant, error-free production system landscape to enable the company's business processes to run smoothly. To achieve this goal, they should consider:
- To separate development from production so that changes in the development environment do not become effective immediately in the production environment
- To test every change before it goes live
- To ensure a stable test environment
- To test in a test environment that is as similar as possible to what is expected to be in production environment (with respect to Customizing and repository)
To summarize, the system administrator must be able to rely absolutely on the results of the final test before importing the changes into the production environment.
The Three-System Landscape
The three-system landscape separates the development environment from the test (quality assurance) environment and the production environment.
In this scenario, all changes are created in the development system DEV (maybe after prototyping in the sandbox system SBX).
The quality assurance system QAS is used as a testing environment for integration testing and data conversion testing. This system partially contains the changes from the new release that currently is in development. The QAS system is the environment for the final integration test (once the scope of the release has been fixed – release test), regression test, and technical system test. It should represent the status in the production system PRD in the following way:
Infrastructure: the setup of the QAS system should mimic PRD as closely as possible and it should be a full copy of the production system. This is the prerequisite for realistic volume tests.
Transports: The QAS system must not be "corrupted" with new release functionality or new maintenance packages until the appropriate time (ideally as close to go-live as possible).
Data: The QAS system should be regularly refreshed from PRD, if possible.
Assume an SAP ECC system landscape on an old release serving one or several countries. The major development cycle and the rollout are complete. Ongoing changes are limited to Support Packages, operating and database patches. SAP configuration changes are required to support minor business requirements.
In this case, a three-system-landscape might be sufficient: the maintenance transports are bundled into projects, so that they can be tested together.
This scenario works well if the number of urgent corrections is low. Non-urgent corrections should be released later, so that QAS stays close to PRD for the test of urgent corrections.
A three-system landscape can be considered as best practice landscape for solutions with production support and development projects of a minimum scope (even in parallel releases). However, a strong change control (what changes move when into QAS, when will a refresh of the QAS system happen) should be in place.
Hint
A three-system landscape might be sufficient for development projects using the waterfall model, where the whole project is tested together and goes live together. When you use an incremental and iterative development approach, however, a more complex landscape (such as a four-system landscape) should be considered.
The Four-System Landscape
In times of invasive changes (for example, during implementation of Support Packages), it might be useful to introduce a fourth system to support the maintenance of the production system.
A four-system landscape can be considered as best practice landscape for solutions with production support and development projects of a medium scope (even in parallel releases) as it allows for a staged testing. Similar to a three-system landscape, a strong change control (what changes move when into PRE, when will a refresh of the PRE system happen) should be in place.
During the implementation of Support Packages (or other minor releases), in DEV only urgent changes, standard changes and smaller non-invasive functional enhancements are developed. Here, PRE is required, for example, for testing of urgent changes during the time periods while the Support Package or the minor release is "blocking" QAS.
Hint
It is important to move the Support Packages fast through the landscape in order to limit the time period of inconsistent releases in the landscape. A reduction of the transition time for the Support Packages can be achieved by thorough testing in the sanddbox system SBX.
Besides the four-system landscape with a pre-production system, other variants of a four-system landscape are possible as well. The following figure shows a variant where functional tests are not restricted to the second system of the system landscape, but takes place in both the second and the third system:
In this scenario, functional tests take place both in TST and in QAS. So interfaces and appropriate test data must be provided for both systems.
Note
This is sometimes a problem when the SAP solution is heavily integrated with legacy systems which have only one test tier.
Typically, early integration tests are done by the implementation teams and vendors in TST. Final integration tests, user acceptance tests and regression tests are done in QAS in the final preparation phase of a release.
This landscape allows to test for future releases in TST, even though they are not yet assigned to the next upcoming release. The transport bundle for the next release must be assembled only before the final preparation phase starts.
Dual System Landscapes
In system landscapes in which multiple releases are used, changes can be made in different systems. This allows new developments to be made in the development system, and errors to be corrected or improvements to be made in a maintenance system for the production system landscape at the same time. In this case, a single track landscape in principle does work due to the following limitations and risks:
Challenges and risks arise mainly because all types of changes need to be managed in a single development system and in a single transport track.
Note
In a best practices environment, there are 5 types of changes – emergencies, minor releases, major releases, standard changes, and SAP maintenance.
There are conflicts that will need to be managed explicitly by respective processes. These conflicts will lead to limitation in either the project development or the creation of corrections (one has to wait).
Risk for urgent corrections: The release or development status of the DEV system is different to the status of the production system. Potentially, in DEV, there are new developments active (the objects that need to be corrected have been changed by a new development project).
This is where a dual-system transport landscape comes into play:
The dual system landscape can be considered as best practice in case of large implementation projects (either maintenance or functional projects) in parallel to production support: project changes do not affect the production support landscape – therefore it allows for safe and fast production support at all times.
When to Use a Dual System Landscape?
Dual system landscapes may be used for your most innovative and business-critical systems.
The use of a dual system landscape is a good decision when production support and implementation projects are changing the same business processes, which in turn means that a significant number of conflicts is to be expected due to parallel changes of the same objects. Dual landscapes can be used when major implementation projects or upgrade projects are in the pipeline, these projects typically have a long runtime. In addition, they are useful in case of separated responsibilities of maintenance and implementation in your organization.
A single-track landscape, in contrast, is most efficient for small development projects with a high frequency. It does not require cutover preparation tasks, especially in case of parallel development projects.