I’m often asked why an SAP customer should have a 4 system landscape rather than the typical scenario of just 3 systems – comprising a development system, a test system and the live production system. In this scenario, changes are made in the development system and unit tested there. They are then promoted to the test system for more rigorous testing and once complete and correct, are moved into the production system for live use by the business.

What’s a “pre-production” system for?

What then, is the point of introducing the 4th system into the landscape – sitting between the test system and the live production system? It is often referred to as the “Pre-production” system.

The core reason for having this system is to ensure stability to operational production systems. It is all about making sure that the system upon which you are doing your testing, is as close to production as possible. Many customers I work with mandate that if a change (transport request) reaches the “pre-production” system, then it either must go through to production (in a very short space of time) or it must be “undone”.

The heart of the reason for doing this is due to the way in which SAP’s underlying change and transport system work. When objects that are being changed are released from the development system, they take a snapshot of the state of the object at that point in time and write this data to a file. This is really what represents a transport request (2+ files on the SAP file system containing the binary data representing the state of the objects).

When a transport request is deployed to a subsequent system, it is this copy of the objects contained within the snapshot that is imported. As you can imagine, the “release date and time” of the transport request is critical in determining correct sequencing and has been a fundamental flaw in the SAP correction and transport system since its inception many moons back.

Third-party tools such as ActiveControl are able to understand the nuances of the sequencing and ensure that changes are deployed in the correct sequence and that no “overtake” scenarios occur. ActiveControl was the first product on the market back in 1997 to develop an overtake check and customers using it have benefited enormously ever since.

See Agile SAP development in action with ActiveControl

See how ActiveControl manages multi-track SAP development including merge and retrofit of parallel development activity and even supports Agile development by dynamically monitoring the status of all of your SAP transports.

With a 3 system landscape, the following happens…

1. A change (C1) to object A is made
2. It is released at time T1 upon transport request X (snapshot taken)
3. The transport is deployed to the test environment to undergo testing
4. During testing of C1, a new change (C2) to object A is made for, say, an emergency
5. It is released at time T2 upon transport request Y (new snapshot taken)
6. The transport is deployed to the test environment

At this point, there are no issues detected. Something may come up in testing that doesn’t quite work as expected, but since the latter change is an emergency this may very well be overlooked due to urgency.

Overtake

What happens now is that the emergency change (C2) is deployed to production without first deploying the earlier change C1. This scenario is called an “overtake”.

This will do one of two things:

1. Import into production OK, albeit that the earlier (not fully tested) change C1 has been dragged into production when not ready to go
2. Import into production with an error due to a missing complex dependency which lies on the earlier C1 transport request

Both circumstances are far from ideal and the impact will differ depending on the change that is being made. If the impact is severe, you may need to look into how to back out a change from your SAP system.

A further common issue that happens is that the first change C1 will eventually go through to production – which will regress or overwrite the C2 emergency change. In other words, the earlier snapshot of the object in C1 will overwrite the latter snapshot of C2. The business will be completely back to square one and their emergency change undone.

In a 4 system landscape, because the pre-production system is a much later copy of the production system, then the “overtake” issue should be caught during the deployment to the pre-production system. In other words – it will error during the deployment but this will not affect the production system stability.

So what’s the alternative?

A proper third-party change control tool will be able to manage this situation for you without the cost of having the 4th system in the landscape. And, because the 4th system is a ‘production like’ system, it is likely to be a large data footprint. Add together the hardware costs, maintenance costs and the manual process overhead of deploying transports manually – and it is clear that the removal of a ‘pre-production’ system will cover the cost of a leading third-party tool such as ActiveControl. In fact, this is the most common business case that our customers use.

So customers run a 4th system in their SAP landscape to reduce risk to their mission-critical SAP systems – to ensure that changes deployed to pre-production are done so to a system that is more alike to their production systems. However, they are only doing this because they don’t have a mechanism in place to detect overtake scenarios which are the root cause of their concerns.

I know the above is quite a controversial statement and there can clearly be significant benefits in having a pre-production or regression test system prior to deployment to production. However, the reality for many smaller customers running SAP is that they cannot afford a 4th system in their landscape.

This is not just the cost of the hardware upon which it runs, which often includes having production like data, but also the cost of maintaining this system as well. The primary aim here is to protect your mission-critical production systems and if a customer cannot justify having a 4th system in the landscape, then having an appropriate tool in place to manage change can significantly mitigate the risk to production stability.

If you’d like to know more on the topic of overtake detection and how it works, please request a demo of ActiveControl.