Understanding SAP landscape set-up, and associated challenges – Part 1

How can I put this politely? The technical side of SAP isn’t exactly obvious or welcoming to novices. There are some similarities with other IT systems, it’s true, but plenty of uniqueness exists too. I was reminded of this fact recently when speaking to some of the new starters here at Basis Technologies - the looks on their faces told me I was definitely assuming too much about their technical knowledge.

Following that experience I thought I’d put together some introductory information that could help people who have more recently entered the world of SAP (though hopefully it will also provide a bit of food for thought for everyone else). In this first part (more will follow soon) I’ll look at SAP systems, clients, transports, landscapes and common design / architecture patterns which influence the application development processes for a company using SAP software. Part two will focus on more advanced aspects of landscape set-up and design, and in part three I'll consider ways to help simplify management of the complexity of SAP.

Let’s start with the basics and work up from there. Before we can build a landscape, we need to understand about SAP systems, clients, types of objects / data and the concept of transports

SAP System

An SAP System is an installation of one of SAPs products. The role that the system plays (Development, Production, etc) can be configured and is usually referenced somehow in the System ID (SID) via a naming convention. E.g. 

So, GFD would be the Development System of the Global Finance Landscape, whilst EHP would be the European Human Resources Production System.

Types of Data and Clients

A client is defined as a self-contained commercial, organizational, and technical unit within an SAP System. Some data is stored in specific clients (Client Dependent Data) including Application Data, User accounts and Client Specific Customizing. All business data within a client is protected from all other clients.

Conversely, some data is stored at a system level and is available to all clients in the system (Client Independent Data). This includes cross-client customizing and the underlying repository objects which determine how the system works, including the data dictionary (e.g. tables and structures) and the workbench (reports, programs, and so on).

There are often strong mutual dependencies between Customizing tables. For this reason, tables are not maintained individually, but as Customizing objects. A Customizing object can contain both client-specific tables and cross-client tables. 

Default installations include Clients 000, 001 and 066. Client 000 is basically used as working client only when you do support pack upgrade or implementing additional languages, etc. Otherwise, client 000 should not be used as a working client. 066 is used by SAP for remote support. 

Beyond the default clients, customers are then able to create clients for their own use within the range 002-999. 

System Landscape

A landscape is a logical group of systems based on the same SAP product / release, with different purposes.

The most common landscape is a 3-tier one, meaning that it has 3 systems within the landscape. Typically, these are Development -> Quality Assurance -> Production. Why is that?

Production is considered the priority. It is expected to be used “productively” by hundreds, if not thousands, of users and as a result needs to be available, functional, and stable. This is also the system in which audits are performed, so only production transactions should be executed here. At the other end, we have Development. This is the system in which changes, fixes, projects are all worked on (unless we set up a ‘multi-track’ configuration, which I’ll consider in part two), often by hundreds (or even more) of developers or functional consultants. Sometimes work needs to be backed out or dummy data needs to be created to test new functionality, and such activity cannot happen in the Production system itself, which is “locked” to prevent direct changes to customizing or repository objects (see the section on transports, below) and minimize the risk of unexpected accidents. 

This amount of concurrent activity gives rise to the need for an additional environment that sits between Development and Production, typically referred to as a Quality Assurance system. The reasons for this system are: 

• To provide a working environment that includes ‘production-like’ data (can be achieved by refreshes or test data provisioning)
• To connect with other systems (SAP & non-SAP) in order to test interfaces
• To provide a stable representation of what will be included in the next “release” to Production

Temporary & Optional Systems

Beyond the typical landscape, there can be many other permutations including the following types of systems: 

As you can see, there are many reasons why additional systems may be included into the landscape either on a temporary or permanent basis. 

System Refresh

A system refresh is a way of aligning the data, customizing and repository of a system to ensure that they do not drift apart over time (i.e. contain changes which have been abandoned) and also to ensure up-to-date data is included in the system for testing purposes. A refresh is basically a copy from another system which overwrites what was in the one being updated. It typically includes work to rename the system once refreshed and set up interfaces and user accounts equivalent to their state before the refresh. The decision on whether to refresh a system, and from where, depends upon the type of system in question. A summary of some different options follows:

Transports - Moving changes through the landscape

An SAP Transport Request (or Transport for short) is the vehicle used to capture change and to move it between systems or clients. A Transport can contain customizing and/or workbench contents and goes though the following lifecycle:

1. Transport Creation - creates an empty transport as a container 
2. Change Recording - store changes to customizing, or creation of/change to repository objects 
3. Release Transport – locks the transport contents and enables it to be exported and then imported to other systems/clients
4. Import – process by which the changes contained within a transport are imported into the target system

Whilst originally created to manage changes to ABAP objects, SAP has extended the concept of transports as a way of capturing change to also encompass HANA, BW, Java objects (and more) via the Enhanced Change and Transport System (CTS+)

As you can imagine, during a large and complex project teams of developers and consultants can create hundreds, if not thousands, of transports, which need to be managed and coordinated in a controlled way to ensure that the right ones move to the downstream systems within the landscape at the right time, in the correct sequence.

Conclusion

So that’s it for part one. I hope you have found it useful, either as a primer for your up-coming work in SAP or to spark some re-consideration of how you manage your SAP estate in future. In part two of the blog series, I’ll expand upon these basics to look at more advanced elements of landscape design such as ‘dual track’, 1-to-many and multiple clients. 

In the meantime, questions to consider for your organization might include: 

• How many systems do we require in our landscape?
• When do we need a separate Sandbox system vs using a sandbox client in the Development System?
• How many clients do we require and in which systems?
• Which temporary systems could we need and what would the triggers be?
• Do we need separate tracks for specific project developments?

If you’d like more information on how Basis Technologies’ automation software can help you to more safely and effectively manage the kind of clients and systems I’ve just described, feel free to get in touch.