OCC ABAP Cleaners OR How to tidy up the Core

[Siarljp]

To clean or to tidy-up?

In this blog I intend to go over what for many is perhaps old ground, over what is a dirty SAP core, and how to then tidy-up this core.

OC-Cleaners

Excuse me whilst I digress a bit. One of my wife’s favourite shows on TV is a show for all of us core tweaking ABAP’ers to watch “OC-Cleaners” – it’s a fun ride where a self-confessed “OC-cleaner” is called in to solve a situation that has somehow developed at someone’s (often a “collector”) residence. Quite often the residents are mystified as to how they ended up in quite the pickle that they now find themselves in (often it's hard to get in the front door without tripping over stuff), and the cleaners are quite frankly horrified too. There is great entertainment to be had watching the reactions of the OC-Cleaners and the collectors.

For several years now since Teched 2018 (I was lucky to attend Barcelona) and in many publications since, SAP has been repeating the refrain “Keep the core clean”, You could say SAP are the original SAP OC-Cleaners. SAP’s stated main driver for delivering S/4 HANA was simplification (that's what the S in S/4 stands for). S/4 is essentially a clean-up of the core systems design of its code and data model. I think SAP then realized that they also need their customers to follow on this simplification journey with custom code, or all of their SAP simplification efforts were wasted. We can question how completely SAP achieved this (a topic for another day perhaps), but this lead to the mantra "Keep the core clean".

The questions that many developers then raise is “What do SAP really mean with keeping the core clean?” AND/OR “How do we get to a clean core?" and then "How to keep it clean?”.

We will attempt to answer these questions here. The cleaning also concerns customer over how to retain all of their added value custom developments (mirroring the collectors anxiety over throwing away all of their stuff), whilst at the same time receiving all of the very latest tech that SAP are now delivering in abundance (see my other blog on Storm in an SAP BTeaP cup). As previously mentioned Wouts blog I found goes into some deep thinking around what is meant by a clean core (see Wout's blog here "keep the core clean considered harmful) – I will describe my interpretation here; and then explain that perhaps we don’t need to be so much OC-Cleaners (which as Wout points out actually maybe harmful to us) and more perhaps SAP core tidiers (or one small step at a time).

OCC SAP Cleaner

Typically the residences at the start of the OC-Cleaners show resemble our core SAP custom code bases today, after several years of happy custom coding. Even the best customers of SAP at some point resort to very necessary changes in and around the SAP core. These changes we make parallels what happens at the OC-Cleaners (OCC) tv-show collectors' residences, we buy new stuff (make new core changes) that we want to use ASAP, we use it, and then don’t place to much thought on placing it tidily in the right place (get the design right), then we go out and buy some more stuff (accumulating code debt), eventually all this stuff start to stack-up blocking access to the sofa... The problem is that our code bases over years of work tend to evolve organically (rather like the OCC collectors residences), and developers (often under delivery pressures) prioritize performing changes as quickly and as simply as possible (mvp-style (minimal viable product)), with a view that value can be achieved as quickly as possible, something surely every customer wants?

These kind of organic changes, usually work fine at the start and value is achieved from a customer perspective, whilst at the same time the changes begin to accumulate. What initially seemed like a small piece of isolated code and the quickest and best solution, may on reflection after a few years, have lead to a “spaghetti like” code base, after repeated changes. Essentially this is an OCC episode at the start, a nightmare scenario and a “Code Debt” situation, where we have left items of code blocking access to our needed simplifications for regular upgrade and or S/4 upgrade changes, we are in danger of tripping over the user exits, mods, implicit enhancements, before we can reach the promised hallowed simplified lands of S/4 (or the sofa).

Now at the time where many of us are getting ready to upgrade to S/4, where we have many code changes to perform, the ongoing practices of quickly performing core coding tweaks inside the "AB core" is leading to a continually more complex code conversion for us all, and additionally this journey to S/4 becomes more tricky with each new code tweak that is performed. You might think “the sooner we invite in the OC Cleaners the better!”. However in place of full-on cleaning out changes, I propose instead we tidy up the core one bit at a time.

Tidying up, in terms of ABAP, is essentially a process of code redesign and refactoring, encapsulating and separating concerns, one bit at a time.

A clean core is not so much a core without custom ABAP, but it is a core with well designed and clearly interfaced and carefully encapsulated custom code. This code is then far easier to deal with during upgrade situations, and you have more flexibility in terms of future redesigns. Its the customers code that we want to focus on here, as that’s what we can influence and customers perhaps, didn’t quite get the cleaning message, where the cleaning is really needed, and this is a result of the message I think being a little bit undefined.

A key tidy-up target is tight coupling.

Tight coupling is the enemy of agile delivery, and is really the knots in the tangled mess of the dirty core. What do we mean with tight coupling?

Wikipedia defines coupling as “In software engineering, coupling is the degree of interdependence between software modules; a measure of how closely connected two routines or modules are; the strength of the relationships between modules.”

To decouple code cleanly we must aim for a separation of concerns, together with a clear purpose and a clear interface for each code change. The good news is, that this is not a new problem to computer science, and computer science boffins have been thinking on and around this challenge for many a year. This thought process has partly lead to the principles of S.O.L.I.D. coined by Robert C. Martin (SOLID is one of the foundation stones of the Agile coding movement). Many aspects of SOLID are very relevant to our core changes and can be applied to our SAP custom development today in the effort to help us tidy up the core, and many of these principles I would argue SAP are following themselves today (just not everywhere, even for SAP is in a code tidying journey).

The primary type of code we need to really look out for is where code dependencies are not clearly respected.

So what sort of things are we considering with “Core changes”? In Wout’s recent blog he argues it is changes inside the Application Boundary (the AB).

For code within "the AB" I think about traditional user exits, function exits, changes made using the enhancement framework (Non BADI), implicit enhancements, and then straight out modifications to SAP Standard (having worked in and around SAP customers for many years, I can say most customers using ABAP have examples of almost all of these kind of changes in abundance).

The clean code movement also introduces the Boy-Scout rule, which is essentially “always leave the campsite cleaner than you found it” which I think points to the real solution. In other words, constant incremental tidies wins over a full clean-up. Incremental tidying up the core then should be the goal, and really it is a step by step exercise in code refactoring and redesign, with the aim to decouple and eliminate the tight dependencies.

SOLID

To decouple core code we should be aiming to follow SOLID principles, just to list out the core principles (without fully diving into the detail):

Single responsibility - Give it a “single responsibility” (keep it simple) “A class should have one, and only one, reason to change”

Open for enhancement, closed for modification - Enhancements (think of the framework) we understand in SAP as well as modifications (direct changes to SAP code).

Liskov substitution - Liskov means to honour your contract, the behaviour of a class/interface should be consistent across its implementations.

Interface segregation - Decouple using class-interfaces

Dependency inversion - breakdown and eliminate dependencies

When first looking at a core change, ask yourself, is this code encapsulated and performing a purpose for just one responsibility? So a change requirement coming from one area of the business won't necessarily impact another unintended area (for example). So try not to merge multiple responsibilities into a single class, try not to do too much. If you have code serving multiple responsibilities probably the best solution is to split the responsibilities to multiple classes (and avoid coding direct dependencies between classes). Document what the responsibility is that your encapsulation is performing clearly (or make it clear in the naming), also briefly document the possible impact of that responsibility not being fulfilled (if you can and to the best of your ability).
Try to keep the methods interfaces clear, clean and simple. Each method should be understandable from its naming what it is trying to achieve.

Open for enhancement, closed for modification.
With the enhancement framework SAP have kindly provided us with what is arguably a best practice way to apply core changes. That is the usage of Kernel BADIs (see a good blog on these by Joseph), a Kernel BADI (or business add-in) is a defined enhancement point that uses a class-interface definition and a class implementation of that definition, you can then apply filters to that implementation for finer control, then there should also be a default implementation for a kernel BADI. The BADI when executed, executes efficiently within the kernel. The advantage of the BADI definition is that they place a clear contract (Liskov) and interface point that any enhancement is bound to, essentially they state how they interact with standard code clearly. As such it can be simpler to lift and shift these definitions (say in an S/4 upgrade situation), than for code where the interface and scoping is less clear. BADIs come with encapsulation designed into them, although you should still follow the principle of single responsibility and try to keep them simple. Kernel BADIs are preferable (to non-kernel BADIs, now considered obsolete) as they are implemented in a fashion that means no performance penalties for the implementations. If there is no standard BADI definition provided, I would argue to place a custom kernel badi definition at the point where your enhancement is needed (even though this may be technically a modification (Yikes! OC Cleaners and Mr Martin are now coming after me) its still a modification where you are stating "I will add a controlled and well kept piece of code here"), if no clear enhancement point exists.

I usually strongly recommend against implicit enhancements, as these are very similar to open modifications, and without clear scoping. They are changes that SAP are certainly not expecting you to make, and changes that are very likely to be impacted during upgrades, and so best to avoid, but if you do need them, then encapsulate and follow SOLID principles. Avoid at all costs cloning SAP standard combined within implicit enhancements.

Some of the other principles of SOLID also apply, but those come bundled to an extent when following the kernel-BADI technique.

So what is important is that for every custom change we make in the AB core we take time to encapsulate, and then aim for singular responsibility.

 

The Boyscout rule (Robert C. Martin)

We can incrementally follow our journey to a tidier core by following a principal of clean code, and that is:

If we tidy the campsite, each time we camp (every time we make a change) so that we always leave the code cleaner after a change than it was before we started. Following this habit, then eventually the core will be a tidier place, and less need for the OC-Cleaners to invade our systems!

So I would argue that in place of a message “keep the core clean” instead we should be aiming for “Keep the core tidy”.

Addendum: When I asked SAP-BTP experts a little while ago over what they recommend to keep the core clean, the answer they give appears simple, although not always practical, and quite distant for customers to achieve: “take your core changes and move them to side by side solutions”.

Side by side is great in certain use cases, and certainly leads to a decoupled solution, but it is usually several giant steps away, and not always achievable even in the medium term for many SAP customers, as for instance you may need to really get under the hood of the standard solutions to really gain the advantages you as a customer need, or perhaps you need real-time access to some really big tables, there can be many reasons why you consider you need to build close to the core. So completely cleaning the Core is often not an option (sorry OC Cleaners, SAP and the misses😉).

Just remember step 1 to reach side by side is separation of concerns and encapsulation, and so the above recommendations are a small step on the way to perhaps one day reaching OCC nirvana.