Landscape is like a server system or like a layout of the servers or some may even call it

the architecture of the servers viz. SAP is divided into three different lanscape DEV, QAS
and PROD.
- DEV would have multiple clients for ex: 190- Sandbox, 100- Golden, 180- Unit Test.
- QAS may again have mutiple clients for ex: 300- Integration Test, 700 to 710 Training.
- PROD may have something like a 200 Production.
These names and numbers are the implementer's discreet on how they want it or they have
been using in their previous implementations or how is the client's business scenario.
Now whatever you do in the Sandbox doesn't affect the other servers or clients. Whenever
you think you are satisfied with your configuration and you think you can use it moving
forward, you RE-DO it in the golden client (remember, this is a very neat and clean client
and you cannot use it for rough usage). As you re-do everything that you had thought was
important and usable, you get a transport request pop up upon saving everytime. You save
it under a transport request and give your description to it. Thus the configuration is
transported to the Unit Test client (180 in this example).
You don't run any transaction or even use the SAP Easy Access screen on the 100 (golden)
client. This is a configuration only client. Now upon a successful tranport by the Basis guy,
you have all the configuration in the Testing client, just as it is in the Golden client. The
configuration remains in sync between these two clients.
But in the Testing client you can not even access SPRO (Display IMG) screen. It's a
transaction only client where you perform the unit test. Upon a satisfactory unit test, you
move the good configuration to the next SERVER (DEV). The incorrect or unsatisfactory
configuration is corrected in Golden (may again as well be practised in the sandbox prior to
Golden) and accordingly transported back to 180 (Unit Test) until the unit test affected by
that particular config is satisfactory.
The Golden client remains the 'database' (if you wanna call it that) or you may rather call it
the 'ultimate' reference client for all the good, complete and final configuration that is being
used in the implementation.
In summary:
Landscape : is the arrangement for the servers
IDES : is purely for education purpose and is NOT INCLUDED in the landscape.
DEVELOPMENT ---> QUALITY ----> PRODUCTION
DEVELOPMENT : is where the the consultants do the customization as per the company's
requirement.
QUALITY : is where the core team members and other members test the customization.
PRODUCTION : is where the live data of the company is recorded.
A request will flow from Dev->Qual->Prod and not backwards.
1. Sandbox server: In the initial stages of any implementation project, You are given a
sandbox server where you do all the configuration/customization as per the companies
business process.

2. Development Server: - Once the BBP gets signed off, the configuration is done is
development server and saved in workbench requests, to be transported to Production
server.
3. Production Server: This is the last/ most refined client where the user will work after
project GO LIVE. Any changes/ new develpoment is done is development client and the
request is transported to production.
These three are landscape of any Company. They organised their office in these three way.
Developer develop their program in Development server and then transport it to test server.
In testing server tester check/test the program and then transport it to Production Server.
Later it will 8deploy to client from production server.
Presentaion Server- Where SAP GUI have.
Application Server - Where SAP Installed.
Database Server - Where Database installed.
What is the meaning of "R" in R/3 systems?
R/3 stands for realtime three tier architecture. This is the kind of architrecture SAP R/3
system has.
R/3 means three layers are installed in Different system/server and they are connected with
each other.
1) Presentation
2) Application
3) Database
What exactly is SAP System Landscape? How does this phenomenon differ from SAP
System Architecture? In this posting, I intend to answer the above mentioned, closely
related questions in a very concise manner, with particular emphasis on the system
landscape of SAP. Often times, SAP users, especially new comers misunderstands the two
concepts.
The SAP architecture is typically the technology framework of the SAP system. SAP's
architecture unlike the system landscape has changed over time (and more recently) with
the advent of SAP ECC.
In a prior posting, I "x-rayed" they system architecture of SAP R/3.
They system landscape basically is the set-up or arrangement of your SAP servers. Ideally,
in an SAP environment, a three-system landscape exists. A three-system landscape
consists of the Development Server-DEV, Quality Assurance Server-QAS and the
Production Server-PROD. This kind of set-up is not primarily designed to serve as server
clusters in case of system failure, the objective to enhance "configuration pipeline
management".

A Typical SAP Three-System Landscape.

At this juncture, it is important to state that a test system - Sandbox can also exit separately.
The essence of the sandbox is to test the configuration of the business processes of a
company, especially at the inception of the project (before the Business Blue Print is
signed). It can also serve as a practice environment, even after go-live.
Pipeline is the environment where the configuration in the development system is moved to
the quality assurance system and finally to the production system. The whole idea is to
ensure that the configuration of these systems is in sync at any point in time. Suffice to say
that, configuration/changes are first made in the Development system, thoroughly tested in
the Quality Assurance system before been loaded into the production (Live) system.
This approach throws up the transport management system concept. Transport
management system is the coordination of the movement of objects and configuration
changes from the development system to the Quality Assurance system and then to the
Production system. At times, this sequence of movement is not possible, especially in cases
where an SAP note mandates that changes be made directly on the production system.
In such rare cases, objectively confirm that the change transport cannot be performed. Very
likely, your system must have been configured to "not modifiable" (a system locking strategy
that enforces the three-system landscape change transport rule); unlock the system by
changing the global setting option to "modifiable" using transaction SE03. After you have
done that, effect the change(s) on the system. Immediately lock the system back by
changing the global setting option to "not modifiable" using transaction SE03. Replicate the
changes on the other system. Note that transaction SCC4 can also be used to lock the
system so that client dependent and independent configuration changes are not carried out
directly on the production system.
By and large, the SAP system landscape ensures that the integrity of data is enhanced via
enforcing a controlled configuration changes effect on the target system - production.

System Landscape
The system landscape contains all the SAP Systems that you have installed. It can consist
of several
system groups, whose SAP Systems are linked by transport routes.
After you decide which
clients you need and which roles you want them to have, you need to decide how to
distribute them amongst the different SAP Systems. You can set up multiple clients
independently of one another in a single SAP System. However, when you configure the
data, you must remember that cross-client Customizing settings and Repository objects are
identical for all clients in a single SAP System. Changes made in one client apply
immediately to all clients in the system.
Three-System Landscape
We recommend a three-system landscape in which each of the central clients has its own
SAP System.
This consists of a development system DEV, a quality assurance system QAS and a
production system PRD. The development system contains the Customizing client CUST,
the quality assurance system contains the quality assurance client QTST and the production
system contains the production client PROD.
Make all changes to Customizing data and Repository objects in the Customizing client.
When you release the corresponding change requests, they are transported into the quality
assurance client. This means that changes to cross-client data only appear in the quality
assurance client after the transport. In the quality assurance client you can test whether the
transports are complete, or whether any linked changes are missing and are still in
unreleased change requests. If the test is successful, the change requests are transported
into the production client. The production client is completely separate from the other clients
as regards cross-client data.
If you need other clients with additional roles you can set them up in one of the three
systems. Set up the development test client (TEST) and the prototype client (SAND) in the
development system. Set up the training client (TRNG) in the quality assurance system.
Two-System Landscape
A two-system landscape is an alternative for smaller SAP implementations where little
Workbench development takes place.
The two-system landscape does not include a separate quality assurance system QAS. The
quality assurance client is also in the development system DEV.
As in the three-system landscape, the production client is completely separate from the
other clients. The disadvantage of a two-system landscape is that cross-client data is used

in both the Customizing and quality assurance clients. This means that any changes that
are made to cross-client data in the Customizing client can affect the tests in the quality
assurance client. You can also not guarantee that transports from the Customizing client will
be complete. Although all tests in the quality assurance client were successful, errors could
still occur after the transport into the production client. This problem is caused by changes
being made to cross-client data and then not being transported.

One-System Landscape
We do not recommend a one-system landscape containing all central clients in a single
SAP System. Joint usage of hardware resources and cross-client data places serious
restrictions on how a single system operates. In particular, once the system is used
productively, you can no longer develop in it, unless you stop productive operation for the
development and test phases.