The introduction of XXS/RISE with only two systems
SAP® offers S/4HANA® Cloud, private edition (PCE), in an XXS size, which is the smallest one. This option is intended for smaller organisations with between 60 and 135 Full User Equivalents (FUEs). This allows smaller companies to run the full gold-standard ERP capability for smaller enterprises – and as an ABAP stack enthusiast of 20 years, I’m pleased to see the announcement.
Can you run a business on a two-system landscape in the cloud?
Three-system landscapes
In years gone by, there was often confusion around the term ‘three-system landscape’. Back in the days of R/3, people would wrongly assume this was what the ‘3’ related to (the actual meaning of R/3 was the three layers of computing – Presentation Server (SAP GUI on a PC), Application Server (ABAP Runtime) and Database Server, and this was key to the scaling capabilities of SAP in the 1990s and early 2000s). The three-system landscape was equally crucial to the success of SAP in that period because it enforced correct change management and testing processes. The doctrine was that code changes and customising changes was only possible in a development environment.
These then had to be transported, potentially with approval steps, to a ‘consolidation’ system where the code/customising could not be changed but could be vetted, and tested with better data. As a result of this being so hardwired into the ethos of SAP developers, business analysts and other SAP professionals, the suggestion that someone only requires a two-system landscape can cause some considerable dismay.
There only ever were two systems
For a long time now, I’ve been of the opinion that you only really have two systems in the landscape. The Development system was likely installed as part of the initial implementation, as was the Production system (some methodologies may have copied Dev or a QA to make Production, but it is rare). Every other system you see is just a copy of Development or Production at a point in time. They are ephemeral. For larger organisations, I believe with effective change management you could spin up disposable QA systems, leveraging the elasticity of the cloud, use them for a set period and delete them when that project or phase passes. Projects could even run concurrently in n+x environments as long as the timelines of when each will reach Production are understood and adhered to. With an effective Test Data Management (TDM) solution (spoiler alert – I work for a vendor of one) you could even limit the data scope of such systems to certain company codes, only master data or even just the data for a particular Project. This could save considerable costs compared to a full copy of Production.
Effective landscape design for PCE XXS
In the case of XXS, I think there is a simpler solution. SAP allows multiple clients per system. So that the non-production system could house a development client (e.g. 100) and a QA client (e.g. 200), customising changes made on 100 could be moved to client 200 via the SCC1 transaction before the transport is even released. Testing can then be carried out in 200 with a good set of data. Again, with a good TDM solution this could be a subset of production and be anonymised, but standard SAP tools could also be used to copy Production directly (check in with your audit compliance team though on ‘real’ data in test systems). The anonymisation is particularly important in this system because someone with a developer key in client 100 can read data from client 200 via the code they write.
Additional temporary clients for specific projects could also be leveraged and then removed afterwards.
For those migrating existing SAP workloads to the cloud, it is a matter of mapping the existing System/Client Combinations to the new ones. This act is not trivial since the clients housed on an existing QA system will now become additional clients on the development system, and therefore the repositories must be reasonably aligned between the two systems. For many years we have leveraged our TDM solution to rebuild development systems as part of a migration to the cloud to remove the differences between Development and Production, and that is something I would recommend could be considered in the migration to XXS/RISE. There is more information on rebuilding development as part of a project here.
Upgrades and complex projects
Any major upgrade, or complex project, may push towards a full refresh of the test system from production. In this two-systems layout, that needs deeper consideration as a result of the fact that ‘test’ also houses the development client. With accurate data and change management there is no need to refresh non-production systems, but if it were to be carried out some additional steps must be taken to ensure ‘work in progress’ changes are closed out and transports released ready to reapply. There is also the option to temporarily take a third system to act as a testing system for the more complex projects.
Harness the power of SAP BTP
The one important consideration is that code changes in client 100 will have an immediate impact on the other clients. So, projects and ‘BAU’ will have to co-exist on a permanent basis. But for most small enterprises, the amount of ABAP change will be limited since the default option should be non-ABAP enhancements via BTP. There is the optional third system, for those who really feel they require it, but for this size of organisation I would caution against that.
The company I work for hires tech graduates every single year. One of the big challenges we have is to coerce the bright young things coming through that ABAP is a good language to become an expert in. Python, Java, Kotlin and Swift are seen as much cooler (I’m probably showing my age here just by using the word cool). The gnarly old ABAPers with cross-functional knowledge are becoming harder and harder to find. The ones that helped support the massive growth of the ABAP stack systems in the noughties are retiring in their droves, and with the code remediation requirements for larger organisations moving to S/4HANA those that are still in the workforce will be in high demand up to 2027 and perhaps beyond. So before investing in custom ABAP code, tables, BADIs etc I would strongly urge organisations of this size to take a ‘BTP first’ approach to any business requirements which are not covered by the standard functionality.
I’d even go further than that, to say the functionality of SAP’s flagship ERP systems may have had some blind spots back in 2003 but by now it has vast coverage when you consider the different industry verticals in which SAP is the leader. The business team should also consider whether the process in question would be better to follow the approach of the SAP system. There might be efficiencies to gain in dealing with the supply chain as a result but you also might weed out some ‘that’s the way we’ve always done it’ inefficiencies.
And of course, if you’re still determined to use ABAP after all that, why not consider the SAP BTP ABAP runtime environment which will allow you to do the development outside of the two-system landscape and control the deployment more easily with cross-client choices because the connection between the BTP ABAP environment and your system is client dependent. Such that it can be active on client 200 but not on client 100 of your non-production instance.
For more information on implementation strategies for RISE XXS check out this webinar and handout (SAP Partner-only webinar).
Leave a Comment: