S/4HANA Product Versions

Table of contents

• Introduction
• Versions
• Public Cloud
• Private Cloud
• On-Premise
• Comparison
• Extensibility
• Steampunk
• Embedded Steampunk
• Conclusion

In this article, we'll take a look at the different versions of S/4HANA products, their similarities, and their differences.

 

Introduction

You want to switch to the S/4HANA Public Cloud Edition, but you don't know if your system is even capable of it or what challenges you might face? Therefore, as a first step, you should look at the different versions and weigh their advantages and disadvantages. In this article, we will discuss the different aspects within each version.

 

Versions

Let's first look at the different system versions, how they differ from each other, and what they have in common. To illustrate the differences between the individual releases, the following graphic is helpful:

• On the left, you see a classic ECC system, which represents our starting point before migration.
• In the middle, the various target versions to which migration is possible are shown.
• The right side is particularly relevant for the topics of extensibility and extensions in BTP; we will discuss these in more detail at the end of this article.

© SAP SE

 

Hint: For our explanation, we reverse the order of the different systems and begin with the cloud system.

 

Public Cloud

The Public Cloud solution is SAP's standard product. SAP handles all operations and maintenance, and takes care of upgrades independently. Furthermore, you strictly adhere to the standard processes you would find in an S/4HANA system. Upgrades are provided very regularly in this system, in this case every six months. However, you should be aware that the system's extensibility is severely limited. In the past, extensions were primarily possible via Key User Extensibility. This includes adding fields or information, as well as certain logic adjustments implemented via Cloud BAdIs. Further options were scarce in the past. However, for the last few years, extension via ABAP Cloud has been possible. This includes developing custom applications, tables, or extensions directly on the platform using ABAP and other ABAP Cloud standards.

In the past, public cloud systems were primarily built as a two-system landscape. This meant there was a customizing and extensibility system for development and quality assurance, and a production tenant for live operation. In current scenarios, a three-system landscape can now be requested. This adds a dedicated development system as the third system. This is necessary to efficiently implement and test more in-depth extensions with ABAP Cloud (On-Stack Extensibility) before they are deployed to quality assurance and production.

Another special feature is the automatic upgrade process for SAP Fiori applications that have been extended via extensibility. In this case, after an upgrade, a copy of the original application is first created in the system. This copy must then be manually reviewed and tested by a developer. Only after this review are the extensions incorporated into the original application. Conversely, this means that if the app is not actively tested after an upgrade, the user continues to work with an outdated copy of the application in the system instead of benefiting from the upgrade's new features.

 

Private Cloud

The Private Cloud Edition is essentially a middle ground between the public cloud and an on-premises installation. SAP or appropriately certified partners primarily handle the operation of this version. The system itself is hosted by a hyperscaler of the user's choice (e.g., Azure, AWS, or GCP). Regarding extensibility, the Private Cloud, just like the on-premises version, continues to offer the full range of functions. A customer can therefore decide for themselves: Do they aim for a "Clean Core" approach and use the corresponding modern methods (ABAP Cloud), or do they continue their existing processes as before? The latter, however, often means that outdated technologies such as classic reports or the SAP GUI remain in use. Therefore, the Private Cloud differs primarily in its operating model, but not in the technological freedom of extensibility. An important difference remains the innovation cycle, as new releases are currently only delivered every two years.

 

On-Premise

If you originally come from a classic ECC system that you operated yourself in your own data center, a migration will usually result in an on-premise version of an S/4HANA release. This version currently represents the standard when it comes to the transformation of applications and systems. Many companies are currently busy migrating their old ECC system to a new S/4HANA on-premises system. First, the classic migration scenarios must be considered: This means that the simplification items must be checked and corresponding adjustments made to the system. But are there really no further points to consider after a successful migration? While operations continue to run in the company's own data center or with a partner of choice, and expansion scenarios are not technically restricted, and all existing technologies can theoretically still be used, you should definitely consider the topic of "Clean Core." Do you really want to continue using all the (sometimes outdated) technologies that SAP offers in this portfolio, or are you using the migration as an opportunity for a technological modernization of your system?

 

Comparison

Here you will find a clear comparison of the current versions and features based on various criteria we have selected.

 

When deciding which version to use, the focus should primarily be on the system's extensibility. The key questions to consider are: Can your own processes be mapped in a standardized cloud solution? Or are such extensive extensions necessary that a move to a public cloud is impossible? Furthermore, essential issues such as data security, data protection, and access permissions must be clarified, especially whether the cloud requirements are compatible with the company's internal compliance guidelines. The actual technical operation of the system is therefore often only of secondary importance in this strategic decision.

 

Extensibility

There are various scenarios for extending S/4HANA systems, such as on-stack extensibility and side-by-side extensibility. The following graphic provides a brief overview, although we will not go into detail about the individual scenarios here. These serve only as a starting point for two terms that we want to explain in more detail below to avoid confusion in their use: "Steampunk" and "Embedded Steampunk". These are essentially working or project titles that were used internally at SAP, and not official product names. Nevertheless, these terms have entered common usage when it comes to the architecture or naming of systems.

© SAP SE

 

Steampunk

This is a system that runs in BTP and can be used to build Side-by-Side extensions. The official name is "SAP BTP ABAP Environment", which you will also find in the BTP service catalog. The system is a pure ABAP stack that offers all the core functionalities provided by the ABAP platform. There are no standard modules such as FI/CO or MM on the system. The latest releases are delivered here every three months. This makes the system perfectly suited for training your own employees in the latest technologies and ABAP best practices.

 

Embedded Steampunk

Embedded Steampunk is not a standalone system, but rather an architecture introduced by SAP. It primarily involves using "ABAP Cloud" on the corresponding S/4HANA Cloud systems. With this approach, SAP aimed to expand the possibilities for customizing an S/4HANA Cloud system without relying solely on Key User Extensibility, as was previously the case. The term Embedded Steampunk is based on the fact that the same methodology is used here as on a Steampunk system (ABAP Environment): namely, ABAP Cloud to extend the system using software components to encapsulate the corresponding logic. As is typical for this model, only officially released SAP APIs and objects may be used within the system.

 

Conclusion

Knowing the differences and similarities can be important not only in the consulting business. Companies today face the task of finding the right version for their migration or when completely new to the SAP ecosystem.

 

YouTube
Video