DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Building Scalable Real-Time Apps with AstraDB and Vaadin
Register Now

Trending

  • Exploratory Testing Tutorial: A Comprehensive Guide With Examples and Best Practices
  • Revolutionizing Algorithmic Trading: The Power of Reinforcement Learning
  • SRE vs. DevOps
  • Top 10 Engineering KPIs Technical Leaders Should Know

Trending

  • Exploratory Testing Tutorial: A Comprehensive Guide With Examples and Best Practices
  • Revolutionizing Algorithmic Trading: The Power of Reinforcement Learning
  • SRE vs. DevOps
  • Top 10 Engineering KPIs Technical Leaders Should Know

Understanding SAP Landscape SetUp and Associated Challenges – Part 2

Break down the advanced concepts associated with SAP Landscape Design and how to manage the increased complexity that comes with them.

David Lees user avatar by
David Lees
CORE ·
Aug. 14, 20 · Review
Like (2)
Save
Tweet
Share
7.87K Views

Join the DZone community and get the full member experience.

Join For Free

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. 

Stay posted for part 3 in this series where I'll cover more around the uses of automation software in SAP and how it works to improve the management of SAP landscapes, whether simple or complex. 

Landscape (software)

Published at DZone with permission of David Lees. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • Exploratory Testing Tutorial: A Comprehensive Guide With Examples and Best Practices
  • Revolutionizing Algorithmic Trading: The Power of Reinforcement Learning
  • SRE vs. DevOps
  • Top 10 Engineering KPIs Technical Leaders Should Know

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: