Introduction
You may have heard about the term "Clean Core". This blog will not explain what Clean Core means. I've spend lot of time to get familiar with Clean Core and found many great resources and blogs explaining almost all aspects. I don't want to repeat them here.
This blog series instead focuses on what we learned about Clean Core, what our Clean Core strategy looks like and how we try to get back control about our custom developments.
You may need to get the attention of the Board of Management as well as of your team mates. They may ask for reasons why they should spend time and money in Clean Core. This blog series will try to address this as well by providing arguments
If you're in the same situation than we are, I hope this blog series assists you to define your own strategy and tasks.
Today we will focus on why Clean Core is important for us (and you)
Background
tl;dr; if you're just interested in how we handle Clean Core, skip this section
The company I'm working for uses SAP since 1996. During the past 30 years (almost), a legion of internal and external software developers with different skill levels and professions developed almost everything to meet the requirements of our users. Each developer brought his personal background. Some of them started their career back in the 1970's to 1990's with good knowledge about mainframe and midrange systems (do you remember IBM AS/400 systems? If so you know what I mean). Others joined in 2020 and later bringing good knowledge about object oriented software design and knowledge about web technologies.
With the growth of the company, new processes have been introduced, others has been changed and some are not in use anymore. SAP also evolved over this period and brought us new technologies, products and paradigm in ABAP development. Different skill levels and interests, available technologies, lack of time and documentation multiplied with 3 decades of software development leads to a ton of custom code, a mess inside the code and an incredible high amount of technical debts.
Two years ago, we migrated our ECC system to S/4 HANA. Due to lack of time and budget (again), we've chosen some brown-field approach. We were able to get rid of many development objects but had to keep most of them.
Today we're running S/4 HANA 2023 FP1 on-premise. We use latest SAP technology with added dust of 30 years on top.
Take Away: Innovate and renovate more than 30 years of software development is not a sprint race. It's at least a marathon of several months up to few years with good chance to never reach the finish line. But at least each single step helps you to improve your systems
Clean Core Dimensions
I said I don't want to explain the term Clean Core but it feels like I need to give you a short intro anyway.
Core describes the main aspects of SAP, which can be thought as dimensions and components around
- E2E processes
- Data (also customizing)
- Integration (like 3rd party tool integration)
- Operations (maintenance activities, release management, jobs etc.)
- Extensibility (any kind of added custom function)
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 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.1)
As I'm a developer, this blog will focus on dimension Extensibility only. This doesn't mean that the company I'm working for ignores the other aspects. You seriously need to take them into account as well. Luckily, those aspects are handled by my SAP Basis and Consultant colleagues.
In short, your system is 100% Clean Core compliant of you can operate it entirely in a public cloud scenario.
At least in our case, we couldn't be more far away from this.
Take Away: define responsibilities for each of these dimensions. You can't handle all of them by your own. Sometimes dimensions and responsibilities are not 100% clear.
For example, a developer will not only be responsible for extensibility but also for integration. A consultant will be responsible for E2E processes but those might need an integration to 3rd party tools as well. Responsibility for integration dimension gets shared between Consultant and Developer.
What's the issue if we're not Clean Core compliant?
Even if we don't plan to move your systems into public cloud, Clean Core is important for us as well
| we will upgrade our system at least once a year (we did this only every x years in past) | Each upgrade leads to high effort for reimplementation and testing in both, IT and business |
| we need to enable ourself to use latest technology to bring down implementation effort and speed up development | Today we almost use no BTP product. Products like AI agents (Joule) will not produce valid results in a highly customized (modified) environment. Other tools like Integration Suites will not support outdated technologies |
| we have lots of undocumented processes and extensions | Since we started with S/4, many old guys have been retired leading to accumulated brain drop in IT up to 90 years of working experience, more to come in near future. Due to high amount of custom code and modifications, we encounter high training effort for new colleagues in IT and business. It also leads to high cost for external consultants analyzing our technical debts |
| we run different implementations for the same processes | We have subsidiaries and production plants all over the world. They're almost the same but each of them brings country specific stuff. In past, code has been duplicated for them. Sometimes we developed a solution not being aware that the dedicated requirement already has been solved for someone else. |
| we should be prepared for a future move | Even if there is no plan to move to cloud now, who guarantees that we will not do in future? |
Take Away: define your own issue list. Think about what will happen, if you don't try to clean up your core.
Extensibility
As developer, I'm mainly responsible for Extensibility. SAP defines an extension like this
We as SAP customer need a dedicated function which is not provided by SAP in standard. Maybe a solution is provided by SAP but lacks in for us important aspects. Welcome to the white area where we develop our solutions.
An extension can be:
- A custom ABAP report
- A custom function module
- Z-Fields and appends to tables
- User-Exit and BAdI implementations
- Forms
- Modification of SAP standard objects
Literally any kind of custom development artifact is an extension.
In past, we used almost any kind of extension type. We developed custom reports, function modules, database objects etc, according to our needs. We made use of 3-layer extensibility supported by SAP (table appends, user exits, dynpro exits). We also used modifications, implicit enhancements and we even copying SAP objects and changed them according to our needs.
Duplicating and modifying SAP objects is a bad idea and is one of the main technical debt. These are old news, we're aware of this since ever. There was a good reason for SAP to introduce SSCR keys to track modifications in your system.
Some main drawbacks are:
- High effort for reimplementation and testing during upgrade
- Often undocumented (at least in our case)
- Lost of knowledge (retirement)
But we did it anyway because of:
- High workload and pressure to fulfil our customer needs
- No alternatives provided by SAP but a business critical need
- We only upgraded our system every x years
- Some modifications exists since more than 20 years. No one expected they last so long
What has changed?
These were the main drawbacks and risks we discovered during our first S/4 upgrades
- SAP removes deprecated user-exists we still use. Even if a dedicated user-exit was marked as deprecated and superseded by BAdI, you could use it anyway as it still was executed. SAP didn't remove obsolete stuff in past (remember transaction MB1A? It was still there for years being deprecated). This has been changed and we came across a situation where an user-exit is still there by definition (meaning EXIT_... FM still exists) but was not executed anymore (https://me.sap.com/notes/3414378)
- SAP also removes other deprecated, non-released function modules you might use
- In case of modifications, lot of code has been changed around our modified parts which leads to high effort to reimplement it
- Sometimes, a modification was easy to reimplement, as source code was the same as before. But this code was not executed anymore as the entire source code of a given transaction has been replaced
- New technologies can't be used with ease. Do you think AI agent Joule will be able to produce valid results in a highly customized environment? It has been trained by SAP with their own LLM model. But it can't be aware of any modification you made.
- System will become unmaintainable in future
Conclusion
I hope in this first blog I was able to highlight the importance of Clean Core in general. In the next blogs I will explain our Clean Core strategy in more detail.
I want to finish this blog with a cite from SAP community
„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.“