Introducing the Clean Core Approach


After completing this lesson, you will be able to:

  • Explore exits and modifications prior to SAP S/4HANA Cloud
  • Categorize the components of the clean core approach used by SAP S/4HANA Cloud

Classic Extensibility Approaches

In the world before cloud, this approach was in most respects fairly straightforward to implement for both SAP and the customer. In some respects, it was similar to a contract. There were certain things that SAP provided and certain steps and procedures that customers followed. Imagine a simple scenario where a screen in an SAP application contains two fields: revenue and cost. It would not be too presumptuous to guess that an end user would request an additional field to be added to the display. Let's assume that they did so by requesting a new field to display profit. And let's assume that the profit would be calculated not only using revenue and cost, but also a special numerical factor used by the customer. Since this factor is customer-specific, there isn't a field to hold it in any of the underlying database tables that the application is using.

To implement this type of scenario, SAP would provide what were known as exits to customers. These exits would be located at multiple layers throughout the "stack". Let's look at those layers one by one, starting with the lowest layer: the data layer. In our simple scenario, a developer would use a "table append" to add a new field to a database table representing the numerical factor mentioned previously. Once activated, this field would be available to be read and also to be stored. The table append effectively provided customers with a universal exit concept to adjust the definition of any provided SAP table to meet their unique business requirements.

The next stack layer that needed an exit to be provided by SAP would be the highest – the visual layer. It is here that the new field (profit, in our simple scenario) would be visualized. Visual layer exits consisted mainly of two types: Screen exits and menu exits. In our simple scenario, a developer would utilize a screen exit to add the new field to the screen, and possibly a menu exit to add a new command, which, upon being selected by the end user, would perform the calculation of profit.

The final stack layer that needed an exit would in some ways be the most important. This is because a new field added at the data layer of the stack and seen at the visual layer of the stack would contain a value that would need to be potentially read, used, updated, and maybe even deleted from time to time. These operations would need to be implemented using ABAP code. Thus, code exits that were implemented at the middle (that is, code) layer between the data and the UI were created by SAP. Again, in our simple scenario, a developer would first confirm that a code exit existed to perform any needed operations on the field and then the exit would be implemented with the necessary customer-specific code.

As a result, the customer would have the standard functionality delivered by an application, enhanced with the additional functionality they desired. One important aspect of this approach was that the entire process of utilizing exits was managed by a defined system process. Exits had to be activated. The specific implementation of the exit had to pass all relevant syntax and consistency tests. Development of exits happened in a dedicated development system and were tested in a testing system before being released to end users in the production system. Another important aspect of this approach was that, generally speaking, the development of exits could utilize any SAP object in the system without restriction. For example:

  • Any SAP table could be used for reading and writing records
  • Any SAP function module could be called
  • Any SAP class (and methods thereof) could be used

One final (and important) point. If a customer determined that no exit was available (or was unusable), they could exercise the following two choices:

  • Perform a modification of SAP objects in a manner to achieve the desired functionality.
  • Copy SAP objects. The new object would be customer-owned and thus could be changed accordingly.

As mentioned earlier, a system delivered that features the benefit of customer adjustments as part of its design has to balance certain benefits and certain costs. In other words, when the time comes to apply patches or to upgrade the system, any extensions implemented could theoretically become a problem because the new or updated code from the software vendor could make an extension unstable or even unnecessary. Testing would be necessary to ensure that this was not the case. Nevertheless, even taking that into account, the costs of managing that testing process were reasonable against the benefits and flexibility of extensions. Generally speaking, customer adjustments done as the implementation of exits were less problematic on upgrades as the existence of the exits was known by SAP and could be accounted for. Modifications of SAP objects and/or copies of SAP objects could potentially be much more problematic and had to be tested thoroughly after a patch was applied or an upgrade took place.

This approach has sustained SAP and customers for many decades. From SAP R/3 in all of its versions up to and through SAP Business Suite, through service packs and enhancement packs. However, one reason that this approach has been successful was that systems were almost always located in customer data centers and thus were 100% maintained by customers themselves. What one customer was doing in their system was completely separate from what other customers were doing in theirs. However, a "game changer" occurred. That change was the evolution of SAP ERP to SAP S/4HANA.

Clean Core Concept

SAP S/4HANA Cloud runs in the cloud, and a cloud product is different. All customers use the same base code line and changes are applied to all customers simultaneously. As a result, there is no realistic way to allow each individual customer to implement enhancements in the same way that they could in earlier on-premise environments. Customer enhancements are still necessary, but the rules and processes by which they are done have to be completely rethought and redesigned for the cloud world. Enter another challenge for SAP. Like the previous challenges, this one has also been embraced by SAP.​

The solution is to design an extension philosophy distinctively oriented for the cloud. Enter a new term: clean core. Let’s break it down.​


The core describes the main aspects of SAP S/4HANA Cloud. These aspects can be thought of as dimensions or components and they are oriented around the following:​

  • Processes: The series of actions or steps taken within SAP S/4HANA Cloud that cover the end-to-end (E2E) experience of delivering an outcome or accomplishing a result.​
  • Data: The data contained within and used by SAP S/4HANA Cloud processes. Commonly categorized as configuration, master, and transactional.​
  • Integration: Connecting of SAP S/4HANA Cloud to other solutions for the purpose of sending and receiving data to support process execution.​
  • Operations: Necessary maintenance activities performed within SAP S/4HANA Cloud such as release management, background job management, authorization management, monitoring, and alerting.​
  • Extensibility: Functionality added to SAP S/4HANA Cloud that extends it to address organizational needs that are not met by the standard processes.​


Clean means that for each of the previously mentioned aspects, the necessary approach is taken for it to be up-to-date, cloud compliant, optimized, and perfected, depending on the aspect in question.​

Clean Core

Clean Core is both a concept and an approach to achieve a modern, flexible, and cloud-compliant SAP S/4HANA Cloud. Clean core is achieved by integration and extending SAP S/4HANA Cloud in such a way that it is cloud-compliant, with optimal master data quality and perfected business process governance. With a clean core, customers experience better maintainability, along with lower total cost of ownership (TCO) for SAP S/4HANA Cloud.​

Benefits of Clean Core

Clean core benefits everyone.

To summarize, the benefits for customers are as follows:​

  • Ease of upgrade: Make upgrades non-events, from a custom code point of view.​
  • Fast consumption of innovation: Always on top of innovation technologies.​
  • E2E system security, continuity, and stability.​
  • TCO: efficient use of infrastructure and licenses.​
  • Permanent traceability in all areas of the core.​

The benefits for partners are as follows:​

  • Future-proof and cloud-ready solutions.
  • Promoting fit-to-standard compliance with clean core modular innovation.​
  • Reduction of complexity with simplified consumption of out-of-the-box SAP solutions.

Clean Core Extensibility​

Since this learning journey deals primarily with the extension aspect of clean core, this is the focus of our discussion.​

Clean core extensibility can be summarized as an extension methodology where extensions are kept strictly separate from the SAP application. Extensions access SAP business objects only through well defined, upgrade-stable interfaces".

Notice the first part, "extension methodology". Customers can breath a sigh of relief – extensions are not going away. But notice the second and third parts also: The customer extension is kept "strictly separate" from SAP's baseline and also the extension must use officially defined points that are "upgrade-stable". It is the "upgrade" part that is so important. Cloud system availability is not just a wish list for customers. It is a non-negotiable demand. There must be no chance that a system becomes unavailable simply because a new version of the software is released. The existence of customer extensions does not alter this expectation.​

Clean core extensibility is how the balance between software flexibility with customer adjustments and system stability and availability in the cloud world is achieved. It results not only in faster software deployment, but also easier adoption of software changes, since the core starts off clean and is kept that way using non-disruptive, regularly scheduled upgrades. The concept of clean core extensibility can be distilled in this framework of best practices that a customer adopts in implementing SAP S/4HANA Cloud:​

  • Adopting a policy of zero modifications​
  • Eliminating enhancements that are redundant to standard code and functionality and also eliminating copies of SAP objects​
  • Using released APIs only ("upgrade-stable interfaces")​
  • Leveraging the key user (in-app) extensibility of SAP S/4HANA Cloud to its full extent​
  • Employing the capabilities and services offered by SAP Business Technology Platform to build larger extension applications​
  • Using SAP Integration Suite​

Throughout this course, we explore these best practices. However, there are two important points to note. The first is that because there are two cloud deployment possibilities that customers can choose from based on their unique needs, as well as a third traditional on-premise based deployment option, the specific option chosen dictates exactly which options can (and cannot) be utilized. This learning journey is primarily oriented towards SAP S/4HANA Cloud. The term SAP S/4HANA Cloud is an umbrella term that refers to the cloud deployment possibilities, which are SAP S/4HANA Cloud, public edition and SAP S/4HANA Cloud, private edition (public edition and private edition, respectively). The term SAP S/4HANA refers to the on-premise deployment option. If distinctions must be made between the public edition and private edition, the material will explicitly state so. Unless otherwise stated, assume that the features relevant to the private edition (but not to the public edition) apply to the on-premise deployments also.​

The second point is that existing SAP ERP customers must choose which migration approach to use when transitioning to any of the possible deployment options.​

  • New Implementation: A new SAP S/4HANA Cloud is provisioned or a new SAP S/4HANA system is installed​
  • System Conversion: An existing SAP ERP system is migrated to either a private edition or an on-premise system​
  • Landscape Transformation: A hybrid of the first two approaches​

The intersection of these two choices affects the specific approach and steps that a customer experiences on their journey to migrate to SAP S/4HANA Cloud.​

Log in to track your progress & complete quizzes