I actually set out to write this post about N+1 change control, but then I realized I’d need to describe N+1 landscapes first!  I’m certainly not the first blogger to tell you about the DEV-QAS-PRD landscape that SAP recommends, but I’m going to do my best to explain WHY this landscape is recommended and what additional value is provided by an N+1 landscape before I dive into change control in a future post.

First, let’s cover a few basics.  In the SAP world, a landscape is a set of servers or server capacity that your SAP software is running on.  This landscape can be divided into one or more environments, which are separate, independently-operating instances of your SAP software system.  Though these environments are not dependent on each other, you can copy the contents of one and move it to another using something called a transport.  A transport is a package of the apps and configurations you wish to move, plus machine instructions for how to pack those contents up and unpack them somewhere else.

This might seem overly complicated!  Why bother with transports and environments to run multiple copies of the same SAP system?  Why do you need more than one?  The answer is safety.  As I described in a previous post, SAP exists to automate many of the functions of your business.  If any part of that automation stops working, so do all the business processes that depend on it.  Even for firms that aren’t large, this can easily mean losing six figures a day until the problem is fixed.

To prevent this from happening, SAP recommends that you put your system through a sequence of at least three environments: Development (DEV), Quality Assurance (QAS), and Production (PRD).  These environments act like a series of filters to ensure that when you make changes to your SAP system, any problems will be discovered before the changes are implemented in the real world.  The first filter is the DEV environment.  This is where you build all the new configurations, interfaces, and applications for your SAP system that you wish to use in the future.  Because DEV is isolated, you won’t harm your production environment no matter how bad you screw up in the DEV environment.

Once you’ve built all the changes you want to build in the DEV environment, you transport it to the QAS environment for testing.  In the QAS environment, you perform end-to-end tests that simulate the functions your system will perform so you can find any breakdowns before the system goes live.  When you do find breaks, you don’t solve them in the QAS environment – you go back to the DEV environment, make the changes there, then transport the fixed version to QAS and do all the tests over again.

This procedure has to be followed to make sure the system has a single source of record, a master copy that all other copies are made from.  If you skip the DEV step and build version 1.1 in QAS, version 1.0 that’s hosted in the DEV environment doesn’t have the changes you made.  You no longer have a single source of record.  That means that when someone else comes along and builds version 1.2 in the DEV environment, he will inadvertently un-solve every problem you solved in 1.1 when he overwrites your version with 1.2 in QAS.

The last environment is the production environment (PRD.) PRD is the real thing – processing real orders, handling real money, tracking real shipments. Following the sequence ensures that you won’t have any surprises when you go live.  Unforeseen problems will pop up over  the life of the system, but when they do, you just put them through the same cycle.  Fix the problem in DEV, test the fix in QAS, and load it all into PRD when you’re sure it works.

This sequence does a good job at catching problems, but it’s got a major flaw.  You have one DEV environment in which you have to do all new builds, and you have one QAS environment in which to do all testing.  This means you can only have one ongoing project.  If you’re working on a big, long-term enhancement and an urgent problem occurs in your production system, you have to choose between losing all the work you’ve done and letting the problem go unresolved until the long-term project is complete. It’s possible to address this by setting up a temporary break-fix environment connected directly to production.  The break-fix environment allows you to hack together quick solutions to immediate problems, but because you don’t have access to a QAS environment, you can’t test a new solution with the necessary rigor.  You’re essentially doing your quality testing in the production environment and hoping that anything you break isn’t too expensive.

A better solution is to use an N+1 landscape.  This means that in addition to your normal DEV, QAS, and PRD environments (N), you have one or more additional DEV/QAS environments as well (+1).  This arrangement allows you to safely work on long-term projects while leaving a DEV and QAS environment free to tackle any emergencies that pop up.  Unlike the temporary break-fix environment, the N+1 landscape does offer a full QAS system, so you put new versions through the full range of tests.  It can be expensive to buy or rent the software and infrastructure this landscape requires, but doing so is much cheaper than finding and fixing mistakes in your production environment.

It should be pointed out that the N+1 landscape is not a perfect solution to parallel development.  The two landscapes are separate, so changes in one are not reflected in the other.  (SAP does offer a tool to mitigate these issues.)  Still, the N+1 arrangement provides a critical degree of flexibility for organizations who wish to take on long-term development projects without losing their ability to fix IT emergencies.  Check out our next post, where we’ll give some tips for how to manage change control in your N+1 landscape!

TL;DR: Whether you are making changes in response to an emergency or as part of a long-term initiative, do your tinkering in a DEV environment and test the new version in a QAS environment before putting them into production, where mistakes are much more expensive.  Use an N+1 landscape so you have the ability to do short-term fixes and long-term development at the same time.

Originally posted at: SAP Landscape Basics |

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply