Skip to Content
Business Trends
Author's profile photo Wout de Jong

“Keep the core clean” statement considered harmful


The over-simplified interpretation of “keep the core clean” is considered harmful. Nowadays I still hear a lot of SAP and non-SAP people state that all custom ABAP code is polluting the SAP ERP (ECC, S/4) application and should be cleaned, that is, removed or moved somewhere else.

Dogmatically deciding to move custom (ABAP) code elsewhere is a bad and outright costly idea.

Thinking critically how to automate, optimize and/or standardize your processes to achieve business goals in an economically viable way is a good idea, and always has been. This includes what IT tools/capabilities to employ (like custom ABAP code or BTP or new applications and many, many others). But also to look beyond IT at changing the system as a whole, for example modifying subsystems like the organization itself (departments, in- and outsourcing) and the execution of its processes.

Yes, there are trade-offs… Aren’t there always?


Fortunately, this nuanced view is already expressed in most blogs about “keep the core clean” out there, ever since former SAP CTO Björn Goerke spoke those (in)famous words on TechEd 2018.

This blog is going to follow that nuanced trend, although it won’t look like that at first. Let’s explore “clean core” and its over-simplified interpretation by outlining the context, arguments and consequences. Secondly, I will discuss the nuanced view of SAP (and many others), which SAP-Marketing cannot translate one-on-one into “for custom code, buy more BTP Cloud”. All this combined might make you (re?)consider the usefulness of the “clean core”-mantra. 

In the initial draft of this blog, I provided too much detail, for example on trade-offs and characteristics (-ilities). In the (near) future, in a follow-up blog I will put in detailed considerations on -ilities and trade-offs, and maybe an architectural fitness function, just plainly ignoring the “clean core”-catchphrase. That will be a lot more boring and theoretical to read, I promise. 🙂


The Stage

So what does “keep the core clean” mean?

Some (journalists, analysts, a few SAP-employees, partner employees) have defined/described it as “back to standard application, no over-customization in that application”. ChatGPT (version 20230323) describes it as “keeping the central system, or ‘core’, of an SAP installation as free of customizations as possible”, which is a good summary of what was out there on the internet on this topic until the end of 2021. Oh, and for all the ancient SAP consultants (me included) out there, here is some typical SAP-naming-confusion: the SAP-term “customizing” (tcode SPRO) has to do with configuring the existing features of an SAP application, while the term “customization” applies to developing/modifying features yourself in an application (custom code).

So let me make it a bit more concrete. Here is my interpretation of “core” in the SAP ERP context: it is all software (code) that runs inside the application boundary (AB) of the ABAP  runtime of S/4, ECC, R/3.

(I’d like to be more precise, ie all objects in ABAP-table TADIR of SAP ERP, but there are some exceptions. For clarity I leave the (HANA-)database runtimes (HDI, or the old repo), and the UI-runtimes (like browser, SAPgui, apps) and designtime-tooling outside this boundary, but with extra cognitive effort these can be incorporated just as well. Higher-level-frameworks and executable models like Workflow and BRF+ are actually part of the AB, although this eventually might end up in philosophical discussions about “configuration” vs “customization” or “what is code?”.)

Everything developed inside the AB by the SAP-company is considered “clean” according to the over-simplified interpretation above. Customer developed code inside the AB is considered “dirty”; these are all the customizations running inside the AB. I’m not sure where that leaves SAP-certified 3rd-party-addons, let’s leave that out for now. So hence the over-simplified statement that started this blog. Hold your horses, I get to the nuanced part later…

Some SAP-customers even take the “clean core” concept a step further by not differentiating on who made the code. These customers have migrated away entirely from applications inside the AB of SAP ERP to “keep the core clean” (“scrape the core clean”?) . For example, a customer can move away from the SAP ERP SD module (Sales & Distribution) to a custom built sales app (or some SaaS-app) and integrate with the SAP “core” application. Maybe SAP itself is cleaning the core, look at SAP HCM (Human Capital Mgmt, aka HR). SAP sort of mostly placed this outside the “core” with its SuccessFactors SaaS (with HR-mini-master inside the “core”-AB to satisfy dependencies of other “core” modules, like Timesheets for example. The results at this time are mixed, as S/4 H4S4 inside the AB is an option (until 2040, although lacking new HR developments), as is selecting a package from a different vendor with some custom (integration) code to work with “core” S/4. I believe this all falls under the umbrella-term “best of breed”.

(I’ve wondered whether some configuration also pollutes the “core”. The catchphrase “keep the core clean” is vague and abstract enough to also encompass this. SAP is offering various configuration accelerators like “model companies”, “best practices”, and “fit-to-standard-workshops”, implying that the rest of the configuration is “dirty”. This is way too far fetched, nobody thinks of “clean core” this way.)


Having no custom code at all seemed to be a goal in itself many years ago or maybe still is (?). Of course, outsourcing all complex and expensive business-process-supporting application development plus software maintenance to a vendor like SAP is the main reason why orgs buy or rent common-of-the-shelf software applications in the first place. So molding/mapping/automating one’s business processes by utilizing and configuring ERP’s vast capabilities is considered “better” (faster, cheaper, ..) than to develop and maintain applications oneself. Yes, it’s a good idea to maximize the utilization of SAP Standard.

However, applications are not easily composable, at least not with just configuration alone. Sometimes your standard software is missing a really valuable feature, that doesn’t warrant getting another big standard application with 90% overlap (which also needs to integrate into 1 coherent system). Custom code could help with composing and integrating various modules and applications (of multiple software vendors/builders). The question becomes of where to run (and manage) that custom code, and which “system characteristics” are more or the most important… Here come the trade-offs again.

Custom code inside the AB can also make a solution simpler or better in a particular context than configuration. Forcing oneself only to employ configuration might require extra data entities increasing complexity. I have seen consultants configure another (order)type to solve a business issue that burdened the business users with making choices too early in the process. It was better to have no (order)type and a small ABAP-enhancement that allowed deferring that user-decision to much later time in the process (even considering the extra ABAP-maintenance that this choice caused). The alternative with custom code outside the AB had even more negative consequences. 

(In a general (multi-tenant) SaaS-context custom code inside an AB is almost always impossible or disallowed, “clean core” is already implicit. You are totally dependent on the APIs and data im-/export of the SaaS. The business process horrors I have seen, when half the SaaS data were replicated into a custom code database, because some simple piece of functionality in the SaaS was missing and not on the SaaS vendor’s backlog!)


The Arguments

Those put in the “clean core” camp by me clearly state that custom code should be outside the AB. Let’s go over the arguments. Problems with Upgradability are usually cited as the main reason why to “keep the core clean”. When you upgrade a huge monolith like ECC or S/4, this software-lifecycle-event involves a lot of coordination, as it is one big tightly-coupled-cohesive piece of software (basically there is one version of everything). SAP, the company, provides this new, well-tested and integrated and tightly-coupled version of everything. If you have custom code inside the AB, really nice SAP-tooling for upgrades and code analysis can detect and sometimes correct problematic custom code. Problematic in this case means unsupported ABAP-syntax, or way more likely: incompatible ABAP-calls (into or by SAP-created ABAP) as usually only 1 version of SAP-created ABAP is present. In the majority of upgrades this can be dealt with, but under certain circumstances, it can become a real headache and cause delays. (A lot of strategies exist to alleviate those delays, but especially in multi-tenant-SaaS-contexts some aren’t readily available, like an upstream beta-versioned system (sandbox tier before Dev QA Prod tiers).)

What if you had moved the custom code outside the AB and the other circumstances, like incompatible ABAP-calls, remain the same? Result: the SAP software upgrade goes smoothly, yes, so victory! Not so fast, your (integration or regression) tests fail (soon?), because of either issues in replicated data (dependencies!) or the incompatible calls made by custom code outside the AB. Hold on, you say, one should make the integration loosely coupled (ie backwards compatible, via multiple concurrent versions or something) to avoid this dependency, if moving custom code outside the AB. Well, this trade-off isn’t for free, and if SAP had made it backwards compatible, then the custom ABAP code inside the AB wouldn’t have failed as well. 

That leaves the problem of unsupported ABAP-syntax, but occurrence of this type of problem is even more rare, as SAP keeps (or kept?) the ABAP-language backwards compatible for decades. If your code lived outside the AB in another runtime, that other runtime might also need to be upgraded regularly, giving you similar language-statement problems. Although most non-ABAP programming languages are also very stable concerning syntax. It is the incompatible changes (or frequent/fast obsolescence) of libraries, frameworks or services that will bite you in the non-ABAP world way more often.


What other arguments do we see by the “clean core” camp? Occasionally, I hear that ABAP skills are in short supply. This could be a threshold, but then the “core” itself might also be at risk. Or is the “core” not being developed/modified by SAP anymore because of this lack of ABAP programmers? Could be, seeing more and more BTP-cloud-addons… 

But hey, ABAP is just another programming language, literally “open source” (though that term now more covers the concept of “free source” (as in free speech)) and is still easy to learn, even when a large part of being good at ABAP is to know how to navigate all the functional/business domains of the SAP ERP monolith. If S/4 were to be rebuilt (in T/5?) using a highly popular and abundant programming language/platform (remember Java@SAP during Shai Agassi’s reign?) on par at least with current ABAP/monolith capabilities, would that in itself elicit more “dirty core” enhancements?

This argument loses even more credence, because “clean core” can also be achieved with an extra ABAP runtime outside the AB of the ERP, like BTP Cloud ABAP.


Another argument being used is that new technologies (BTP Cloud, low code, etc) are much more appropriate for building business applications. Wait, is SAP really refactoring S/4 using the latest “new technology” fad? I haven’t noticed it, but that doesn’t say much. 

(BTW, SAP already has multiple “cores” with all its many business applications (“keep the cores clean”?), some built with new technology (otherwise I would become very suspicious: a vendor promoting new technology but using old technology in its own products). How to keep those new-technology-cores clean? I digress and move away from my “core” definition above…)

Of course, new technologies offer powerful capabilities (and sometimes lack old, necessary capabilities surprisingly), but the pros and cons of new technology should be carefully weighed in light of the business outcomes you try to achieve (sorry, trade-offs again).

New (or other) technology always means building outside the AB, a distributed system (application), with all its testing, consistency and dependency management difficulties. Especially tools for (usage, call) dependencies in all involved runtimes (“dynamic coupling” (see the book Software Architecture: The Hard Parts)) are usually absent in distributed systems, although the current focus on “observability” (in microservice architectures for example) shows an evolving toolchain-environment, making it less of a problem. Not to mention the data dependencies (when having to replicate data across multiple datastores), where data-lineage-tools come into play. Perhaps one day such a distributed system will actually feel like 1 system, having similar tools we already have today inside the monolithic AB (such as SCMON, where-used-lists, ATC, and then some more) centrally available across all distributed runtimes.


What I myself do see as a problem with custom ABAP code inside the AB is low quality of the code. Custom code is almost always used by 1 customer (often 1 installation), so it often carries a lot of assumptions and specifics of the customer’s environment and configuration. When the environment changes or the assumptions no longer hold, custom code in the AB breaks (immediately noticeable fortunately). As custom ABAP code can access almost all SAP-produced ABAP code (the surface area is huge, like tables, low-level functions which are for SAP-internal-use) and that often does, one can imagine the dependency-sprawl that could hamper the evolution of SAP ERP (the upgradability issues!). Testing is also an unpopular and difficult topic, especially given the effort of setup and the many (concurrent) side-effects in a big monolith like SAP ERP.

That SAP, the company, even allows the option of custom ABAP so gravitationally close to its own ABAP code (in the same AB), is a big show of confidence in its ABAP platform (and its customers). Customers can use the very same tooling SAP is using (very advanced “eating your own dogfood”, with the ABAP platform being the dogfood). Having all these ABAP capabilities so easily accessible, also made us (customers) use it in not always in the best ways. Extending a standard SAP ERP entity with a couple of fields and abusing standard SAP ERP fields by adding different meanings to these, seems innocent and easy enough at first (“enhancement”, user exit, BAdI). However, as soon as you realize that the business scope/meaning of said SAP ERP entity, is really bigger/different, you scramble to redesign the extra fields out of the ERP entity by creating a Z-entity with a relation to the SAP ERP entity (for example). This way the dependency is from custom code (Z-entity) to SAP ERP code, instead of the other way around with a SAP ERP entity having a dependency to extra custom fields. It feels like an orchestration layer on top, just like some outside the AB-tools do. Unfortunately, a lot of customer (code) projects have progressed too far down the path of adding short-term fixes (with deadlines looming), that it is considered too expensive to turn back and redesign.

SAP ERP is an extremely rich and deep application. It can be applied in very complex environments, and probably your environment isn’t so complex (at least not in every part of the business). So you might want to de-complect SAP ERP by creating new relations (“shortcuts”) between standard ERP-entities, ignoring all intermediate entities. Totally understandable for simplifying SAP ERP, but creating relations between standard SAP ERP entities where SAP hasn’t designed them, is a bad idea. It’s better to automate the heck out of all the intermediate SAP ERP entities, so your business users don’t get exposed to that complexity, while the SAP-designed and -built processes are respected and utilized.

So because of low quality, custom ABAP code gets a bad rep. But hey, “moving your rubbish someplace else” (that is, “keep the core clean” by moving low quality code outside the AB), as one of my colleagues so aptly put it, won’t solve this problem at all of course…

As a sidenote, incidentally one could also look at the quality of some SAP-produced-ABAP (it is very “open” after all), which could raise doubts whether that code should be in the “clean core” in the first place. Maybe we could rebrand the mantra to “keep the code clean” (in line with Uncle Bob Martin’s book)? 🙂 


The Nuanced View 

Enough ranting on the extreme interpretation of “keep the core clean”; it’s time for the nuances mentioned above.

While in 2018/19 SAP’s initial messaging could be susceptible to over-simplified interpretation, in the years since you notice a much broader interpretation of “clean core” emerging in various blogs and presentations. The message is definitely not to rücksichtslos move all custom code out of SAP ERP, but to thoroughly think through all customization options, and to select the best tools for the jobs (in service to the business process). SAP’s first and foremost focus is on the toolbox “BTP Cloud”, which indeed hosts a plethora of services for custom code or custom modeling (anyway, for customization in general), ranging from ML-models, HANA native platforms, low-code platforms, pro-code platforms (cloud foundry), analytical tooling, ABAP Cloud (steampunk), integration middleware to Adobe Forms. SAP is using BTP itself to build and deliver higher-level services and products for customers, which is always a good and trust-inspiring sign (“eat your own dogfood”). For similar and different services there are also non-SAP or non-cloud options on the market, so pick your favorites (or poison?), based on the trade-offs for your use case or sets of use cases.

What all these BTP Cloud and other options have in common is that they are outside of the AB of SAP ERP, but need to integrate with SAP ERP in some way, meaning you get a distributed system as stated above. This integration can take many forms and shapes, like replicating data (in/out), subscribing to ERP events, or calling ERP APIs. Some are loosely coupled (=low cohesion), others are more tightly coupled to your SAP ERP (remember the incompatible ABAP-calls above?). The surface area of integration options can be found at the SAP Business Hub. BTW, SAP calls this solution pattern “side-by-side-extensibility” (SBSE), and in the over-simplified interpretation of “clean core” this was the only option to extend SAP ERP. 

There are times when that surface area is not good enough and the “best” (cheapest, simplest, ..) solution to your problem would be to use code inside the AB. (Again, many multi-tenant SaaS solutions don’t allow this at all…) Well, “clean core” allows this custom code inside the AB to a certain extent (pun intended), and the trend of the last 5 years is that more and more is allowed! Yes, more, but not all. The surface area is not every single piece of ERP code (like in “classical” SAP ERP environments), but a limited but growing set of (released, whitelisted) ABAP artifacts like selected ABAP CDS Views, Classes, Functions etc. This surface area is bigger than the one available to SBSE. SAP reduces the upgradability problem, because custom code is now less likely to run into incompatible ABAP (only dependencies to those whitelisted ABAP artifacts). In addition some ABAP syntax is also forbidden (not having to do with ABAP-syntax upgradability issues, but with the power to bypass the whitelist (and access data in other “tenants”/clients). SAP calls this solution pattern “in-app-extensibility” (IAE). Yes, I’m refusing to use the new names (“on-stack developer extensibility” and “key user extensibility”), because I don’t care who does the custom coding (and shouldn’t there be three types of ABAP, where is “classical”?).

As a sidenote, this whole limiting of the surface area is nothing new, SAP has pursued this at least 2 times in my recollection. In the 90s there was the BAPIfication of R/3 with stable remote-enabled function modules (so geared towards custom code outside the AB). Until this very day these BAPIs are heavily used, and are often wrapped inside the AB by newer ABAP-frameworks (especially for side-effects, like create update delete). Less successful (or less known) is the “ABAP Package (Interface) Concept”, a fascinating attempt at organizing ABAP code (limiting surface area dependencies via package interfaces), as admirably explained by Tobias Trapp over a decade ago. It was optional, all-or-nothing (AB-wide), needlessly complicated, and (therefore?) hardly used by non-SAP-employees.


So with this increasingly broader view of “clean core” you have (almost) all the options for custom code on the table again. SAP calls it “Cloud Extensibility Model” (CEM = IAE + SBSE), and the document describing it is really worth a read. You are not forced to go outside the AB (SBSE) for even the simplest of improvements to your business process and pay the distributed-system-price. Don’t ignore SBSE, however, those simple improvements could turn into some separate piece of functionality, which might warrant investment in external platforms outside the AB. Or, more likely, the already existing external platforms you employ, might warrant you to build an SBSE. Or if you don’t want to pay the distributed-system-price and find ABAP suitable, build your SBSE-like-custom-app inside the AB (yes inside!), while minimizing dependencies to SAP artifacts. I will repeat myself once again: keep considering the trade-offs in your context.

So CEM nudges you to newer ABAP frameworks (RAP and the like), but conceptually it is custom-code-as-usual. SAP in 2022 defines “clean core” 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“. Apart from the new and fancy frameworks, I’m not sure how this is so different from how custom code was applied in the past 30 years? You searched for extension points first (user exit, BAdI, enhancement spot) when embedding custom code in SAP standard. For SBSE-like-custom-apps inside the AB, you created custom ABAP with new entities in Z-tables nicely in separate ABAP Packages and accessed only the minimal set of (presumably) stable SAP-produced artifacts (BAPIs, classes, and unfortunately tables (yeah sorry!)), to keep dependencies manageable. The same for wrapping SAP functionality in simplified interfaces for external applications. You rarely if ever modified standard-SAP-artifacts, only if the benefits outweighed all the drawbacks (upgrade issues!) and alternatives. (Remember how difficult it was procedurally to obtain SAP SSCR Keys? Feature was removed in S/4.)

So we now have a whitelist of upgrade-stable SAP ERP artifacts and ABAP-syntax, that’s really useful, thanks SAP. I will adhere to that as much as possible, but will suppress it if too restrictive, reverting back to “classical extensibility”, which you can do in a very granular way, thanks again SAP. Naturally, SAP has provided tools to easily isolate this whitelist-violating code.

(With regard to the new and fancy framework tooling like RAP etc, I like simplicity, which I do not yet see, as there is a lot of indirection and code generation (of which I’m suspicious given SAP’s poor track record, ie CAF, WebDynpro, ..). So for now I adopt an “explore and experience” stance, until the advantages manifest themselves or not. Anyway, this isn’t relevant for the “clean core” discussion, unless the meaning of “clean core” shifts again…)


I hope this blog has illuminated some perspectives on leveraging SAP ERP, and the role custom code plays. Never stop thinking critically how to automate, optimize and/or standardize your processes to achieve business goals in an economically viable way. Of course, classical IT (especially the I, not just the T) can help big time. SAP has been doing that for more than 50 years, by building such a capable ERP application on top of the powerful ABAP platform. “Keep the core clean” hasn’t brought anything new, only a lot of initial confusion and room for misinterpretation. That is useless at the least, and maybe even harmful.


Cheers, Wout


Originally published: 


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Lars Hvam
      Lars Hvam

      I typically say: empty implies clean, but clean does not require the core to be empty

      Loosely coupling to cloud services, will help the core SAP upgrades, however, as you mention, make it more difficult to test the complete business process.

      Its mostly verschlimmbessern


      Author's profile photo Wout de Jong
      Wout de Jong
      Blog Post Author

      Lars, your second line is a nice and short summary of the blog. 🙂 I would extend that a little with "coupling / integrating with whitelisted ABAP will help the core SAP upgrades, and make it simpler to test the complete business process, but you have traded-in external cloud services capabilities". Doesn't make it nicer, but more complete..

      I really appreciate your German term verschlimmbessern (as a fellow non-native-German-speaker I presume).

      Author's profile photo Andre Fischer
      Andre Fischer

      You are right when pointing out that "keep the core clean" does not mean not to develop anything using ABAP within your ABAP stack your SAP ERP / SAP S/4HANA is running on.

      You wrote that

      "... Apart from the new and fancy frameworks, I’m not sure how this is so different from how custom code was applied in the past 30 years? You searched for extension points first (user exit, BAdI, enhancement spot) when embedding custom code in SAP standard." 

      What you describe here is what has been recommended to our customers for a long time, but unfortunately it turned out that lots of developers have not followed this path and happily called any API that was there whether it has been released or not, because (as you also pointed out) it was possible.

      And this is why starting on premise with SAP S/4HANA 2022 you can follow the approach that we describe in our new extensibility guide Extend SAP S/4HANA in the cloud and on premise with ABAP based extensions (which you have reffered to as well but not prominently enough in my opinion 😉 ).

      Following the approach to build new applications using "ABAP Cloud" will prohibit from the use of any not released API.

      So what has been recommended so far can now be enforced.



      Author's profile photo Wout de Jong
      Wout de Jong
      Blog Post Author

      Hi Andre, yes, the CEM-doc provides a nice scale of "stable APIs" when extending from "business hub APIs" (extremely stable, limited surface area) to "whitelist" (stable, ok surface area) to "classic" (unstable, extremely large surface area). Could have been more prominent, but I've been quite sparse with the refs, footnotes and links overall.

      About enforcement (leaving the ABAP syntax out for now) of a limited surface area, couldn't that have been achieved with the ABAP Package Interface concept? Maybe with some slight modifications. Probably you (SAP) considered this alternative, but rejected it in favor of the "released" (whitelisted) attribute.

      BTW, now that you reacted, I'm very much reminded of code-generation frameworks that do work: the old Duet Enterprise Service Consumption Layer and its evolutionary successor Netweaver Gateway (SEGW). Stuff you (your team) designed and wrote, I think. So RAP is in good hands. 🙂

      Author's profile photo Juwin Pallipat Thomas
      Juwin Pallipat Thomas

      So let me make it a bit more concrete. Here is my interpretation of “core” in the SAP ERP context: it is all software (code) that runs inside the application boundary (AB) of the ABAP  runtime of S/4, ECC, R/3.

      Custom Logic created using the In-App extension stays in the ABAP runtime. Hence, as per this statement, that custom logic is within the core and by implementing In-App extension logic, the core is now unclean.

      I don't think your interpretation is correct.

      Author's profile photo Wout de Jong
      Wout de Jong
      Blog Post Author

      Juwin, maybe that's why I find the "clean core" statement so problematic... 🙂

      Author's profile photo Victor Soares
      Victor Soares

      In my opinion it’s all a matter of comparing the costs: custom code cost vs acquiring of-the-shelves applications. As a rule of thumb custom code will cost 5K euros/object for development + 500K/ object yearly maintenance costs.

      Author's profile photo Sergio Ferrari
      Sergio Ferrari

      Thanks for sharing Wout !

      I believe that initially, during the TechEd 2018, the statement was really harmful and far from the the S/4 and BTP capabilities.

      During the years and the releases I started to see interesting new techniques that were inline with the "Clean Core". Now, May 2023, with S/4 2022 and the latest BTP capabilities including events (EDA) we have really plenty of new interesting ways to satisfy business requirements without using the OLD WRICEF objects.

      I believe the journey is not yet completed but I am very positive that we will appreciate the Clean Core more and more during the future.

      That said that I am with you, I want to add the comment that probably SAP Clean Core has been thought to sustain the S/4HANA Cloud Public edition. Then, for the Private Edition (RISE / on-premise) the things were interesting and the concept extended also to this.

      Last point, literally SAP Clean Core do not explicitly specify S/4HANA. Do you think that the concept also applies to the SaaS solutions (e.g. SAP DMC, SAP IBP, SAP SFSF, ...) ? For these cloud native solutions, Clean Core is forced by design.

      Keep posting!

      Author's profile photo Wout de Jong
      Wout de Jong
      Blog Post Author

      Cheers, Sergio. Indeed, at Teched 2018 I immediately noticed some "not again, we have been here before"-reaction in the crowd. Maybe Björn (and team) expected that, and were just trying to get the ABAP-ers thinking beyond...

      I'm not with you on Clean Core though, but that has most to do with the term itself, because it's nothing new, hence the blog. 🙂 Your concept-question on SaaS is interesting though, that is, I'm pushing it a little further into "how can you integrate with any SaaS (extend), can that also be done inside the Application Boundary without the drawbacks of a distributed system?". Are you always forced to go the SBSE-like-way?

      Depends on the SaaS of course. Various SaaSs have some no-code extension mechanism for adding fields, logic, workflows, reports. Microsoft Dynamics 365 (at least the monolithic, non-cloud-native, single-tenant Axapta part) has a layered system where Partner Companies can build solutions on top of, resembling the 3rd party addon options in SAP ERP.

      Let's say you have Kubernetes-based multitenant SaaS, and you see that as the Application Boundary (AB), which is disputable as a container orchestrator like K8s is heavily distributed of itself. Then I haven't seen options where you can inject your own pods in the cluster(s) or similar, let alone modify source code of a service built by the vendor. What about a completely serverless (AWS Lambda like) SaaS (interesting cost aspects involved I guess), where you can inject your own function in the orchestration/choreography? Not seen this one, but interested in learning...

      So you're mostly forced to use APIs or data exports/imports in SaaS contexts. That must be a very consciously made trade-off.

      (In Open Source projects on Github it's a different story of course.)

      Author's profile photo Juwin Pallipat Thomas
      Juwin Pallipat Thomas

      Now, May 2023, with S/4 2022 and the latest BTP capabilities including events (EDA) we have really plenty of new interesting ways to satisfy business requirements without using the OLD WRICEF objects.

      New and Interesting ways for sure. But, fast and efficient... I'm not so sure. Things which could be done with simple few statement enhancements, now take the event to be thrown to BTP, subscribe to that event back in a consumer app, read the original document, make another API call to save changes on the document, which will trigger another event, that will also be published back triggering the consumer app again, read the document again, then understand that no more changes are required on the document.

      Author's profile photo Sergio Ferrari
      Sergio Ferrari

      Hi Juwin,

      I see you are very skilled and I can understand your point of view. I mentioned events (EDA, event mesh) only to introduce the concept of new paradigms, not only techniques.

      I found this video very exciting Developer Extensibility and Business Events with RAP on SAP S/4HANA Cloud . Did you check it out?

      In addition, SAP SAC instead of ZREPO_ALV can be a big step forward as well as SAP BUILD APPS for certain scenarios. SAP Fiori Elements is key. In the end, I personally believe that leveraging on tools with an higher abstraction layer and a set of more powerful features out-of-the box could be a good approach.

      At times, two perfect ABAP statements in the right place could also be considered the #RightCode to #WriteSAPCode.

      Author's profile photo Julian Phillips
      Julian Phillips

      I really enjoyed this blog, an interesting read - so thanks Wout for taking the time! and its certainly making me rethink again around this topic. My answer to what I think is meant by  "keep the core clean"? is I think roughly in agreement with yours, stop placing unexpected custom code directly within the AB. This is the code that is most likely to experience upgrade issues (in my experience). If the code is expected, and the interface is clear and well defined, (ie BADI implementations) - then its cleanish - and so easier to work with and so more acceptable.

      What I have observed developers doing over many years of code inspections - is writing code organically within enhancement points, often unencapsulated, very little consideration over scoping issues, often with many responsibilities intermingled, and so often a ticking timebomb for upgrade issues. In my mind keeping the core clean should be refined to carefully managing and designing these changes, so that they are clearly and well encapsulated with clear interfaces that are respected. So that responsibility is singular and clear (as per R.C Martins SOLID recommendations), with clear documentation over business value and impact if said enhancement stops working. So perhaps less keep the core clean, but more keep the core tidy.

      Note - I now have a blog on this too - here.

      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      Interesting post on hot subject, thanks for sharing it with SAP Community! (I think it could benefit a lot from tighter editing but that's just me. 🙂 )

      Just recently I attended a Clean Core related presentation for partners. The first part of it was literally "what is Clean Core" and tbh, I came out of this presentation even more confused than before. As you've correctly stated, the original notion was understood as "stop doing core modifications and explicit enhancements and use APIs as much as possible". But, according to the slide shared with partners, these days Clean Core seems like... everything and the kitchen sink.

      (The slides were not marked as confidential, so I presume it's OK to share this here with attribution. And I think SAP totally should be sharing this with everyone. But if I'm out of line here, I'll gladly remove the image or mods can remove it.)

      What was completely missing from the said presentation and many similar publications is specific examples of "dirty core" and how to make it clean. And what are the plans for functionality where a "clean" option still does not exist.

      Author's profile photo Wout de Jong
      Wout de Jong
      Blog Post Author

      Cheers Jelena. About tighter editing, well, fortunately you haven't seen the earlier drafts. 🙂

      Looking at the slide it does cover topics you can't object to, although the clean core description seems too vague to me. The same old stuff we have been doing for decades I think (maybe the wording has changed).

      And a "clean" option generally always exists, just build/buy a distributed solution (extracting data, replicating functionality). Of course, if this proves to be suboptimal (too expensive, cumbersome, too many stacks..) in your case, then you can lobby for a clean, cohesive, supported module/solution at SAP and stick with a dirty, cheap, elegant solution in the meantime. 🙂