A typical deployment landscape consists of a development, test, and production system.   In more complex, highly integrated systems, landscapes optionally incorporate a quality assurance system. Initially, this landscape architecture suffices for stabilization efforts consisting of fixes and moderately complex changes, such as production support changes. However, as soon as major enhancements, such as project implementation, are included, the single development landscape proves inefficient, requiring long production support freezes.

Historically, the solution has been to complete proof-of-concept development in a sandbox environment. Once the project team has a solid design, they move into the development system and initiates a production support code freeze for all but emergency change requests. However, the code freeze often thaws when the business pushes for changes it considers urgent. As production support changes and project changes are coded in parallel in the same system landscape, there is a risk of migrating project code to the production system too soon. Risk occurs when product support development and project development occur in the same system. For instance, a technical change such as Support Packs implemented in the Development system prevents transports from being sent to production.

The N+1 landscape offers a solution that overcomes the disadvantages associated with a single landscape. The solution consists of a set of development and change management practices that allow for dual development paths for both production support and project development while maintaining a single system of change. I discuss a successful implementation of an SAP N+1 landscape and the lessons learned from the deployment. I walk you through the benefits and risks of taking this approach, as well as compare it to more traditional approaches. First, I break down the types of systems involved.

System and Change Categories

The first step to implementing an N+1 landscape is to define the role of each system identifier (SID) and the types of development efforts that are supported. As previously mentioned, a maturing SAP landscape consists of sandbox (SBX), development (DEV), test (TST), quality assurance (QAS), and production (PRD) system instances. The purpose of each system is described in Table 1.

Table 1

Typical SAP landscape system and purpose

The Change Management team, sometimes referred to as Release Management, categorizes change types based on their importance to the business, level of complexity, and impact on other interfaces or systems. For the purpose of this article, my change types are Production Support — Weekly, Production Support — Monthly, Project, and Emergency. Table 2 includes a definition of each change request type.

Table 2

Change type definitions

N+1 Architecture

In the N+1 system implementation model there are two development paths. The primary development effort is called the N landscape and is dedicated to weekly or monthly production support and emergency change requests. The new development path is called the N+1 landscape and is dedicated to project change management.

The N landscape is dedicated to supporting production and emergency changes and consists of the original development, test, quality assurance, and production systems. The systems must remain at the same technical level as the production system regarding kernel, Support Package Stack, and enhancement package. The transport path remains the same: DEV > TST > QAS > PRD.

The N+1 landscape is dedicated to project changes and consists of development (DV2) and test (TS2) systems and, optionally, a quality assurance (QA2) system for highly integrated application environments. The development system is a system copy of the N development system just prior to project start. The test and quality assurance systems are system copies of production. There are no requirements to stay at the same technical level as production. The transport path remains the same throughout: DV2 > TS2 > QA2. Refer to Table 3 for definitions and Figure 1 for the N+1 system layout.

Table 3

N+1 landscape system definitions

Figure 1

The N+1 landscape layout

The development system client strategy remains the same for N and N+1 landscapes. For example, if the DEV system has separate clients for client-dependent, client-independent, and sandboxing development activities, then the same clients exist in the N+1 development system copy.

Synchronized Production Change with the N+1 Landscape

Once the two N and N+1 landscapes are available, project development can begin. However, the project team in the N+1 landscape must be aware of the production change that is occurring on a weekly basis. Otherwise, the results are disastrous at go-live. Consider the scenario in which the project team is isolated for six months developing a materials management (MM) extension. During that time, the production support team has implemented several MM fixes and minor configuration changes. These revisions lead to a problem at project go-live because production changes were ignored. This situation can be avoided by ensuring that production changes are incorporated into the N+1 development environment quickly and in the N+1 test and quality assurance systems regularly.

If the technical code base is the same in both the N and N+1 landscapes — Support Package Stack and enhancement package — once a change has been transported to production, it is then migrated to the N+1 development system (DV2). Unfortunately, if the technical code base is different, then the change needs to be re-keyed, or manually entered, to the N+1 development system. Code and configuration re-keys are required because of the risk associated with moving older versions of SAP objects from the down level code base and overwriting the corrected or enhanced objects. Typically, the transport and re-keying of changes are performed within three days of transport to the production system.

When you transport a production change to the N+1 development system, an error occurs if an object is open for change in the N+1 development system. The Basis team needs to contact the project development team and inform the developer of a code change being put in production that is not accounted for in the N+1 environment. The developer needs to safeguard any development changes to the conflicted objects and then release the transport containing the N+1 object. The Basis team can now proceed with the migration, and the developer can now implement the project change against the updated production object.

These minor code collisions are preferable to the disaster that would occur if production changes were ignored for a long period of time while the project development and testing were being completed. Unfortunately, this lesson was learned at a client site when it chose to postpone consolidation of production support changes into the DV2 early in the project development cycle. The project go-live was postponed as the project development team had to accommodate the many code collisions that resulted.

The N+1 test (TS2) and quality assurance (QA2) systems are required to incorporate production changes. The good news is that the timing is not so critical and can be scheduled around testing efforts. Changes can be transported or incorporated as part of system refreshes. Typically, these systems are refreshed from production periodically as project milestones are reached — for example, after completing a series of project tests. As a part of the N+1 system refresh, Basis re-migrates the project transport package as the final step to ensure that the system is ready for project testing.

Project Go-Live

Once the project development and initial testing efforts are ready for production, coordination is required to ensure that the N landscape’s DEV system remains the single source of change. To complete this process follow these steps:

• Prepare for a production support code freeze
• Consolidate the project and production support development
• Perform final regression testing
• Perform go-live

This process typically lasts between one and two weeks, with timing dependent on the regression-testing schedule. 

Prepare for Production Support Code Freeze

During the project go-live phase, production support is frozen and an alternate system is selected to provide emergency change support. To support emergency changes the N landscape quality assurance (QAS) system is removed from the N transport migration path, refreshed from production, and opened for change. Any emergency change is developed and tested in the quality assurance environment. Next, the N landscape transport path is configured as DEV > TST > PRD and the emergency support transport path is QAS > PRD as shown in Figure 2.

Figure 2

Development freeze support landscape

Any emergency changes regarding project development have to be taken into account. Throughout the final regression test, all project code is incorporated into the N landscape development system. Once the emergency transport has been migrated to production, it is then migrated (or re-keyed if there are technical differences) to the N development system and assessed for project impacts. If there are project impacts, additional correcting transports are developed in the N development system. The emergency transport and any correcting transports are added to the project transport package to ensure the transport order that was used to build and maintain the project in the regression test environment is repeated in the production system. 

Depending on when the emergency change was migrated to production, it is possible that regression test cases are completed. The emergency change has the potential to invalidate those tests. Because the regression test is the project team’s final opportunity to validate functionality prior to go-live, it is important that completed test cases are reviewed for potential impacts. The test cases that are identified as potentially affected by the emergency change need to be retested. For more information, refer to the “Emergency Change” sidebar.

Consolidate the Project and Production Support Development

SAP best practice ensures that every production system has a single system of record that maintains all versions of changes that migrate to production. To adhere to this best practice, the N+1 development transports (DV2K*) are transported into the N landscape development system (DEV). This concept is the same as incorporating vendor transports into your landscape.

Prior to transporting the project code into the DEV system, ensure that there are no open transports in DEV, as you do not want any transports failing on the import. In addition, it is important that the release package of transports is complete and is transported in the same order as the transports were sent into the final N+1 test system. 

Once the project transports have been migrated to the N landscape, the N+1 development system should be closed for change. DV2 is now only available as a reference system; any changes to project code are made in DEV. This lesson was learned during the first project go-live following N+1 landscape implementation. By leaving DV2 open for change, developers become confused about where project corrections were made. Simply ensure that only one development system is available, DEV.

Although the transports could remain identified as sourced from the N+1 development environment (DV2K*), my preference is to reset the system of origin to the N landscape development system (DEV). This is a preference and not a requirement and primarily to reflect the incorporation of project code into the N landscape. This process is accomplished via transaction code SE01 using Transport of Copies and Relocation Transport without Package Change, and then selecting the transports. SAP provided this functionality to support the N+1 development as described in the SAP Help screen labeled: You can use this request type if you want to develop objects in another SAP System on a temporary basis: https://help.sap.com/saphelp_nw70/helpdata/en/57/38e1a94eb711d182bf0000e829fbfe/content.htm.

Perform Regression Testing

Next, it’s time to test the DEVK project transport package. Ensure that the project transport package list includes any additional emergency transport requests and correcting transports, and then transport the project to QAS. The assumption is that QAS has stayed in sync with production and does not have any orphaned change. In the event of orphaned change, perform a system refresh.

QAS is now ready for regression testing. It is important to keep a tight schedule when performing regression testing as the length of the production freeze depends on how long regression testing lasts. In environments in which the business has become used to rapid responses to its production support change requests, you might be pressured to include urgent changes. Refer to the “Emergency Change” sidebar for detailed risks and cost associated with including minor changes and emergency changes. This adds unnecessary risk, but can be avoided by staying focused on minimizing the freeze window while performing a complete regression test.

Perform Go-Live

Once regression testing has been successfully completed, the project is ready for migration to production (Figure 3). You have successfully implemented a project with greatly reduced risk and minimized production support downtime, while adhering to SAP best practices associated with a single source of change, without allowing transports from sandboxes or having transports between different code bases.

Figure 3

Project go-live migration strategy

Prepare for the Next Project

To prepare for the next project return the N landscape path and systems to production support configuration (DEV > TST > QAS > PRD) and prepare the N+1 environment for the new project. To complete this process, follow these steps:

• Refresh TST from PRD.
• Optional: Refresh QAS from PRD.
• Refresh DV2 from DEV.
• Refresh TS2 and QA2 from PRD.
• Reconfigure the N transport path to DEV > TST > QAS > PRD.

Options and Lessons Learned

Although the application that I used as an example in this article is SAP ERP Central Component (SAP ECC), other SAP applications (such as SAP NetWeaver Business Warehouse [SAP NetWeaver BW]) are candidates as well. Consider the risks associated with the consolidation of change when contemplating the N+1 landscape for other SAP applications. For example, in the SAP NetWeaver BW environment, you need to take into account issues related to the globally unique identifiers (GUID) associated with SAP NetWeaver BW objects when two development systems are supporting a single production instance. (See the sidebar “SAP NetWeaver Business Warehouse GUID” for more information.)

The success or failure of the project using an N+1 landscape rests on ensuring that the rules are followed. Take no shortcuts and don’t make exceptions. Each system refresh and rule is designed to minimize risk. Keep these four N+1 landscape rules of engagement in mind:

1. Ensure clean starting points for each project development effort by refreshing DV2 from DEV.
2. Ensure the N+1 development environment is updated in a timely fashion (less than 72 hours) with every change made to production.
3. Ensure test environments accurately reflect production by refreshing TS2 and QA2 prior to project testing and incorporating production support code changes on a regular basis.
4. Do not waiver on the definition or rules associated with emergency changes.

You can never communicate too much with production support and project team members. Ensure that the rules of engagement, system purpose, and the life of production support and project transports are clearly explained. When you roll this out for the first time, I recommend poster size printouts that summarize your system information.

Encourage communication among the production support and project team members, especially when they are working on the same objects. This communication avoids surprises when production support transports are moved into the N+1 landscape or at the project go-live.

The N+1 landscape can be implemented as a permanent or temporary landscape solution.   A permanent solution is required when projects happen constantly with project cutovers occurring regularly (quarterly, semiannual releases). A temporary solution is appropriate when production support is the standard way of doing business and a one-time project (e.g., a major technical upgrade) comes along. For more information on the N+1 landscape temporarily used in support of technical upgrades, reference the attachment that is maintained as part of SAP Note 1620751.

N+1 requires many system refreshes to support the testing efforts; therefore, it is important to have an efficient refresh strategy. If your refresh strategy takes days and not hours, then take some time to review your capabilities. Leverage the storage hardware’s capabilities for completing the actual physical copy of the data using storage area network (SAN) tools. At a minimum, script the database rename portion of the refresh and then review each refresh step for the ability to directly execute against the database. The SAP system copy guides provide detailed instructions on completing system refreshes, and the transactions used are often single threaded.

Michael A. Moore

Michael A. Moore has been an IT consultant for 24 years with more than 12 years of experience as an SAP technical architect. Mike has held positions with DuPont, Westinghouse, IBM, and Accenture. His clients have included public sector, consumer products, manufacturing, and financial companies. For the past seven years, Mike's career has focused on SAP technical architecture, where he is responsible for SAP financial, logistics, asset management, and business intelligence solutions for a US federal public sector customer. Mike received his bachelor's degree from the University of Tennessee at Chattanooga and holds numerous certifications including PMP, ITIL Foundations, Certified Scrum Master (Agile), and several SAP certifications. 

You may contact the author at mikeamoore@comcast.net.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.