Abstract: This blog post explains the differences between the various operating options for SAP S/4HANA, including HEC Multi Tenant Edition, SAP S/4HANA Extended Cloud, Private Edition, and On-Premise System, and provides recommendations on which options are best suited in different scenarios. The choice of operational options depends on various factors, such as company size, IT strategy, and operational requirements.

 

Due to the fact that SAP itself has now very consistently entered the cloud computing market, a variety of alternatives are now available for the operation of S/4HANA systems. Depending on who you are talking to, these alternatives have a very different nomenclature, which is often confusing even for the interested SAP expert. In the following I will try to unravel the whole thing and explain the most important terms as simply as possible. Here, I start from the different operating models as represented by SAP itself:

One SAP operating options

Source: SAP SE

 

Differentiation of the physical operating levels

In principle, it makes sense to distinguish between the physical operating level and the application level when clarifying the terminology.
At the physical site level, two main types can be distinguished:

On-premise:

This means that the computers on which the S/4HANA (and possibly other SAP software) is installed are physically located in our data center or as a cluster at an outsourcing service provider that operates them exclusively for us. The hardware on which applications and databases run is therefore exclusively available for our use. In this case, we usually have a decisive influence on the architecture and sizing of the underlying computers.

Cloud:

This means that the computing power we need to operate our S/4HANA system (and possibly other SAP software) is provided by an appropriate service provider – the key players in this environment are currently a number of SAP system and consulting companies as well as SAP itself with its HEC (Hana Enterprise Cloud), which, like most others, is based on Microsoft’s Azure Cloud.

 

Differentiation at application level

At the application level, the differentiation is essentially based on the extent to which the individual elements of the affected application architecture are exclusively available to us, or to what extent we “share” their use with other companies. The following are the common distinctions under this aspect – starting from the one with the lowest individual degree of freedom to the one with the highest (I will speak in the following only of the productive system and neglect development, integration and Q systems):

Multi Tenant Edition (MTE) in the HEC (SAP):

In a multi-tenant multi-tenant cloud, a cloud provider shares infrastructure, applications, or platforms among multiple customers so that they share all resources. The advantage: The provider itself manages scalability, security and upgrades in the multi-tenant cloud. The disadvantage is that a company cannot control its ERP applications independently very well. In the multi-tenant edition in the public cloud (multi-tenant (MTE), i.e. multi-tenant cloud), we are provided with our own client. This means that although we are the sole user in the client-specific area, we share the client-independent area (i.e. client-independent customizing and development) with the other users of the cloud; ergo we do not have the freedom to make individual changes in this area just for us, but are rather obliged to use or not use what SAP offers as a cloud operator. Against this background, this solution is probably particularly suitable for companies whose processes are almost 100% in the best practice processes (link) or who have the strategy of being 100% there. In my estimation, this is most likely to affect smaller companies or companies with a very manageable number of (simple) processes, such as consulting firms, for example. In the public cloud, so-called subscription licensing is used, which means that the licenses are not purchased, but are paid for after use of the individual functions and this is dependent on the volume.

In all cloud solutions, the administration of the SAP system (SAP Basis), the databases and all other components below the application itself is handled by the cloud operator.

In the MTE, it is mandatory to participate in four release updates per year at the times defined by SAP.

SAP S/4 Hana Extended Cloud (also known as Single Tenant Edition – STE) in the HEC (SAP):

Single-tenant cloud deployment – sometimes referred to as a hosted or managed service – typically involves greater control over the environment. Single-tenant cloud means that an organization gets dedicated access to the cloud infrastructure, apps, or platform. It is similar to running a private cloud for that application, except that it is hosted in the SAP HEC ecosystem. This in turn facilitates integration with other applications or services running at the same cloud provider. In the Single Tenant Edition (STE), we are the sole tenant of the infrastructure and are of course provided with one or more database instances of our own for the ERP; this means that we are the sole user in both the client-dependent and client-independent areas and therefore have the freedom to make adjustments in both areas. However, these are also subject to strict restrictions in the SAP HEC. For example, all add-ons from third-party providers that you want to use in the STE must be certified by the provider at SAP for operation in the HEC! This can lead to massive delays in the project; therefore, before deciding to go into the SAP HEC, one should have all necessary add-ons certified for operation in the HEC. The same applies to self-developed programs and data objects. You can find a corresponding classification in the different solutions for permitted changes in this presentation. This shows which changes are permitted in the public and private cloud. There are also restrictions in particular on the use of the communication infrastructure (API). The following links provide information about the communication options (BAPIs and IDOCs) available in SAP’s cloud solutions:

In the cloud as well as on-premise, BAPI’s, Idocs from S4HANA and also the cloud API’s can be used, which are listed in the SAP API Hub at https://api.sap.com/

Full integration is available for S4HANA Public Cloud, Ariba, SuccessFactors and OnPrem systems. Like a customer’s own on-premise system, you can extend and modify it as you wish, including displaying data via SAP tables with your own user-defined interfaces (read, write). The same applies to STE as above, with important limitations: The SAP code must remain unchanged, that is, customers cannot change the SAP code.

 

Available BAPIs and IDocs for integration are documented in the following notes (Note: to access the SAP Notes, you must log on with your SAP S-User):

https://launchpad.support.sap.com/#/notes/2506411 : iDocs available in the S/4HANA cloud for integration into SAP On Premise solutions.
https://launchpad.support.sap.com/#/notes/2447593 : BAPIs available in the S/4HANA cloud for integration into SAP On Premise solutions.
There is a good blog which is worth checking out the STE implementation.

This cloud solution also uses subscription licensing, which means that licenses are not purchased, but are paid for after use of the individual functions and this is dependent on the volume.

In all cloud solutions, the administration of the SAP system (SAP Basis), the databases and all other components below the application itself is handled by the cloud operator. In the STE, it is mandatory to participate in two release updates per year at a time defined by SAP.

SAP S/4 Hana Private Edition in the HEC (SAP) Addendum Dec. 2020):
Probably due to massive customer pressure (I will address this in BLOG post 23 in January: “Our recommendation based on experience: “Hands off SAP’s HEC STE!”), SAP has recently launched a new variant: the private edition in the HEC. This is 1:1 the same infrastructure as the HEC STE, but with a different contract form with significantly fewer restrictions. This concerns:
– The use of third-party add-ons (these no longer require certification).
– No more obligation to perform release updates
– No predefined standards to be adhered to for in-house developments

So you get a quasi completely independent SAP environment in the HEC of SAP – quasi on-premise possibilities in the context of a subscription licensing. On the one hand, it will be interesting to see to what extent this can be reconciled with SAP’s other value propositions regarding the advantages of HEC use, and on the other hand, it will be interesting to see how the SAP HEC team intends to operate these different concepts in the same cloud. Mature concepts come differently, so I recommend studying my BLOG post 21) afterwards.

On-premise:

In the case of on-premise installation, we have installed our own applications, whose licenses we have acquired, on appropriate hardware (on-premise or in the cloud) and per se we operate them, including the administration of the SAP system (SAP Basis), the databases and all other components. Of course, with this solution we are completely free and independent with regard to adjustments and extensions of the S/4HANA system and we also have no specifications that we have to comply with with regard to release updates – with the exception of those required by law, of course. This solution is probably the one that is and has been most widely used for operating SAP R/3 systems. Of course, in this scenario alone, there are also the most diverse make or buy questions that should be answered seriously, especially with regard to the outsourcing of the computer operation including the administration of the SAP system (SAP Basis), the databases and all other components below the application. In most companies, these are not among the core competencies for which they are on the market and therefore it is usually advisable to buy them competently and thus be able to guarantee a generally more stable and cheaper basic operation – or you can turn the tables and offer this service to other companies as an additional extension of your own portfolio. Many companies have already managed this successfully, as I was able to learn in the course of various SAP outsourcing projects that I supervised.

 

The following scheme gives a good overview and orientation to move through the combinations resulting from the possibilities described above:

OnPremise PublicCloud operating options

 

Use On-Premise in the SAP HEC or Non-SAP Cloud

With regard to on-premise installation in the cloud, I would like to point out what I believe is the key difference between using the on-premise solution in SAP HEC and on-premise installation in a non-SAP cloud: In the SAP Cloud SAP HEC, SAP provides the structure of the entire architecture, whereas you can define and design the architecture yourself when installing in a non-SAP cloud, which like HEC is usually based on MS-Azure. This can have a significant impact on costs and performance, which is why I would generally advise you to compare the two alternatives if you are considering an on-premise installation in the cloud and get advice from an expert (I would be happy to make the appropriate contact).

Conclusion:

In my perception, many (manufacturing) companies still focus on an on-premise installation and this mostly on on-premise hardware. Hardly anyone dares to use the single-tenant edition in the SAP cloud, although this has the only significant difference compared to an on-premise solution and if you really have said goodbye to (proper) modifications, the only significant difference is the obligation to make an annual release update – and that would be very welcome in many companies. Of course you also have to get along with the API functionalities available in the cloud (see above mentioned link) and keep your potential extensions within the limits allowed in the STE. But if this is the case, the use of STE should also be a serious consideration for manufacturing companies and should be included in the decision-making process from a total cost of ownership perspective.

AND THAT IS FORTUNATELY ALSO TRUE – SEE HERE BLOG POST 21
“Hands off the HEC STE of SAP!”

To a good finish:

I have deliberately not commented here on the cost aspects of the various solutions, as I believe that in this context it is virtually impossible to make any statements without considering the specific situation and weighting of the individual aspects. Also, I have certainly not been able to fully include all aspects in all variants; I hope, however, that I have succeeded in giving a first overview and orientation.

Addendum Dec. 2020: In BLOG post 21 – “Our recommendation based on experience: “Hands off SAP’s HEC STE!” I report on our experience with SAP’s HEC STE in the recently completed project. It has put a lot of what I said at the time I originally wrote this post into perspective very clearly: Operating a new S/4 HANA system in the cloud can be a very sensible solution, but it should be done with a partner that is mature and experienced enough to also operate such a solution in a secured manner and with a fully comprehensive service – SAP is probably not currently one of them. Since there is now also the possibility for other providers to operate the entire operation of S/4 HANA as a SAAS solution in subscription licensing, one should place at least as much value on the selection of the suitable partner as on the selection of the deployment model – and not under any circumstances succumb to the mistaken belief that the large SAP as, in addition, manufacturer of the software must be the best partner!