BTP - Make the core clean: session follow-up

[Alexander_Korne]

Introduction

In this blog post I would like to summarize the ideas, presented by Lukas Bretschneider at one of the sessions in terms of BTP - Rise program. The session was dedicated to clean core approach, and to this approach in context of BTP and SAP S/4HANA in particular.

This approach means, that the coding we create does not harm any upgrade in particular and we make code, which runs well with SAP S/4HANA Cloud in general.

Main principles

There are 4 main pillars of this approach:

1. Avoidance: stay as close as possible to standard - without losing the flexibility to adapt the business processes to your needs at a fast rate.


2. Decouple extensions for Upgrade-stability:
   
   
   
   • Custom extensions do not break an upgrade and upgrades do not break extension
   
   
   • Usage of released interfaces & technologies to standard objects
   
   
   
   


3. Open to "location": leverage the full of extension options (In-app-, side-by-side or hybrid) which fits best to your needs


4. Be aware:
   
   
   
   • of your technical debts and evaluate them on a regular basis
   
   
   • of your custom code footprint and manage/monitor on a regular basis
   
   
   
   

Benefits

So, what benefits brings us the clean core approach?

1. Reduce TCO by making upgrades eventually non-events from a custom code point of view:
   
   
   
   • Reduce test efforts for business users
   
   
   • Reduce adaption efforts for developers
   
   
   • IT service providers being able to offer upgrade projects at a fixed price
   
   
   
   


2. Speed and Innovation:
   
   
   
   • Be able to absorb innovation delivered by SAP at a faster rate
   
   
   • React fast on changing business requirements
   
   
   
   


3. Be cloud ready
   
   
   
   • If you run your SAP S/4HANA system on premise - already lay the foundation today to move to the cloud from a custom extension perspective
   
   
   
   

How to keep the core clean

Let´s discuss this question based on the example of SAP S/4HANA Cloud.

The following ways of extensibility are available for SAP S/4HANA Cloud:

1. Key user extensibility:
   
   
   
   • Field extensibility
   
   
   • UI adaption
   
   
   • Custom business logic
   
   
   • Custom business objects
   
   
   • Custom CDS views
   
   
   • Custom analytical queries
   
   
   
   


2. Side-by-side extensibility (this type of extensions are developed on BTP side and connected with SAP S/4HANA cloud via Events and APIs):
   
   
   
   • Custom code
   
   
   • Partner extension
   
   
   
   

So what are the general rules:

1. Utilize Key User Extensibility to create custom fields and custom logic ("cloud BAdI")


2. Create de-coupled extensions in Side-by-Side approach


3. Access standard objects via released APIs/Objects (e.g. I_Product instead of MARA)


4. Consider abstraction layer in case of missing APIs/released objects to minimize technical debts

Typical Extension in SAP ECC/ S/4HANA on-premise vs Clean Core extension with SAP S/4HANA Cloud

Let´s shortly take a look, how the stated rules work from technical point of view.

Here it is graphical overview of the ordinary possibilities, which were actively used and in use now in terms of standard on-premise extensibilites:

So in yellow we see classic integration parts in terms of ABAP developments.

And there are "replacements" for these parts in clean core extension approach for SAP S/4HANA:

Approach example

Let´s take a look, which measures can be considered as preferable and which should be avoided based on the stated principles on on example - add custom fields to SAP Business Objects in SAP S/4HANA Cloud:

1. The first and most preferable way, which should be considered is In-App Extensibility: "Custom Fields and Logic" app to define custom fields + automatic integration in APIs, Applications


2. As the less recommended option but still acceptable, we can think about classic extension of DB tables with Customer Includes (CI_*) or Append Structures:
   
   
   
   • "Losing" cloud multitenancy
   
   
   • manual extend all relevant Apps & Services
   
   
   • Only feasible if In-App Extensibility is not available
   
   
   
   


3. Then we are going to much more complicated way - Side-by-Side scenarios (e.g. by creating separate persistence in SAP CP). This option is forbidden for standard tables/business objects due to possible issues with transactions´ security and very high development efforts.


4. The last idea, which can come in our mind is direct table modification. Needless to say, which consequences this approach will have by upgrade.

How to clean the core

We already discussed, how to keep the core clean. But what to do with all the legacy unclean code, which most of the companies have to the moment of migration to cloud. Following measure should be taken into account - get transparency:

• 
  
  
  
  • Retire - evaluate, whether this code is really necessary
  
  
  • Back to standard - maybe it was improved
  
  
  • Replatform to SAP BTP or on-stack refactoring, doing the replacing by clean code
  
  
  • Be aware of the technical debt
  
  
  
  

All these steps for sure should be repeated as many times, as necessary to cover as much legacy code, as possible.