In part one of this blog I provided a high-level introduction to SAP Systems, Clients, Landscapes and Transports, and how they might fit together in a ‘standard’ configuration. But like life, SAP tends to be a bit more complicated than that. The reality of marrying architectural constraints with complex business needs means that the kind of simple landscapes I described in my last piece often will not do the job. Something more complex is required.

In this article – part two of three – I will look at some of the more advanced concepts associated with SAP Landscape Design and how to manage the increased complexity that comes with them. 

Advanced landscape designs: 

Multi-track 

When you need to perform major work in a Development system (perhaps for a large-scale project, or a major upgrade) you might choose to create a parallel landscape in which this work can proceed independently of Business As Usual (BAU) changes (often at a slower pace). This can allow a level of separation between the project activities and the BAU ones, minimizing conflict and thereby avoiding the need for a change freeze or moratorium (which in less technical terms we might also call an innovation freeze, since it means that nothing new or improved gets delivered to users until the lockdown is over). This setup is often known as dual track or multi-track, depending on the number of projects involved (we also see this expressed as N+1, N+2 or more generically N+N, where ‘+N’ represents the extra tracks).

In this scenario it is important to identify when the same object or customizing is being changed in both development systems and to highlight this to the respective developers. 

In addition, BAU changes are almost certainly going to be deployed to Production during project development. If these are not going to overwritten (and therefore downgraded or removed) when the project is finally deployed, they need to be merged into the project track so that it remains reflective of the state of the Production system (this merge process is sometimes also known as retrofit, or dual maintenance).

For exactly the same reasons, it’s critical to merge project changes back into BAU Development and Test Systems after they’ve been deployed into the live Production environment.

As you can imagine, this scenario becomes more and more complex as the amount of change in each track increases and more parallel tracks are added for additional projects (we have some customers who have used N+10!!)

One-to-Many

A less common landscape configuration is one-to-many, in which a single development system is the source for changes in more than one Production system. This setup is typically used to manage a consistent “template” across production systems or to deliver customizing by region or subsidiary. Multiple systems are used to allow for different system downtime windows and to reduce risk of an outage affecting the whole company. In terms of managing change in this type of landscape, we need to consider workbench (repository) and customizing separately. 

Repository objects can be created and distributed either concurrently or in a staggered way to the different regions (e.g. to allow one region to be a “pilot”) for the new solution. Recall that repository objects are client independent. This is an easy way to ensure that all systems (regions in this case) are using the same solution – ideal if you have a goal of process standardization. 

Customizing (client dependent) on the other hand can be managed also in a single development system but can be differentiated by client to, for example, allow only Europe customizing to be sent to the European systems.

One of the differences with customizing changes is that they can also be deployed between clients in the same system. Imagine that a certain portion of customizing is considered to be standard across all the regions – this would be referred to as a “template”. This could include the Legal Entity model or currency rates. In the example below, global “template” customizing will first be distributed to all the regional clients in the development system before they are distributed to the regional tracks. 

An alternative landscape set-up could offer the ability to separate by region using a standard single-track set-up where all clients reside on the same QA and Production systems. Whilst this could allow reduction in infrastructure costs and complexity, it would require all regions to share the same downtimes and for repository and global customizing changes to go live in a “big bang” way. 

Finally, multiple clients could be used within a single development system to differentiate between a “Golden” client where changes are expected infrequently, a Development client in which work in progress is happening and a “Unit Test” client in which validation is being done prior to the transport moving to a QA system. This also allows for frequent refreshes of the data (specifically within the unit test client) as one of the common issues with a development system is that it does not contain representative or meaningful test data. 

Conclusion

As I’m sure you’ve already worked out, when you combine all the different aspects that we have considered so far the permutations for how you might design your landscape are endless: 

• Number of core systems (e.g. 3 Tier – Dev – QA – Prod)
• Temporary Systems (e.g. Maintenance, Trial Cutover)
• Number of tracks (N+N) to handle projects or upgrades
• Number of clients in development to differentiate customizing in a 1:many landscape
• Number of clients in development to differentiate use, control and data (e.g. golden, unit testing)
• Desired frequency of system (e.g. QA) or client (e.g. Unit Testing) refreshes 

Every SAP customer is different because every business is different, and so their SAP landscapes come in many different shapes and sizes. One property they often have in common though, especially when all these considerations have been taken into account, is an SAP landscape configuration that is really difficult to manage safely, confidently and efficiently. 

But that’s why – shameless plug alert – Basis Technologies created ActiveControl, our DevOps automation software for SAP. In the next part of this blog, I will explore why you need a solution like ActiveControl to help you manage your SAP change and release process, from the most simple to those needed in the kind of complex landscapes I’ve described above. 

On the other hand, if you’re excited to know more and can’t wait for the next article to be published, why not request a demo today?