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).

#devops