Taking Control of Clean Core: When to Use Project ...

LBretschneider

TL;DR

Measuring SAP Clean Core involves a choice:

As a RISE with SAP customer, you can benefit from the out-of-the-box standard approach with SAP Cloud ALM. The RISE with SAP Methodology Dashboard provides you with a high-level standardized view with minimal effort.
Or you can choose an open-source, highly flexible, and customizable approach with Project Kernseife. You get custom classification to create actionable insights, but it requires ownership and additional effort.

This article will help you decide which path is right for your team's Clean Core journey.

How the RISE with SAP Methodology Dashboard measures Clean Core

SAP's answer on how to measure clean core is based on two standard tools: The ABAP Test Cockpit (ATC) (and its newly released checks as from SAP Note 3565942) and the RISE with SAP Methodology Dashboard in SAP Cloud ALM.

The process begins with the ATC, which analyzes your custom code against a well-defined set of rules. The key to this analysis is the classification of your custom extensions based on the official release status of the standard SAP objects they utilize. This release information is transparently published by SAP in the Cloudification Repository (Viewer).

As described in more detail in the Clean Core Extensibility Whitepaper (see chapter 3.3), the ATC assigns your extension a level based on the most critical SAP object it utilizes:

Level A - For extensions using only stable, released objects, ensuring maximum upgrade security.
Level B - For extensions whose most critical dependency is a classic API like a BAPI or classic technical frameworks.
Level C - For extensions touching any unreleased, internal SAP objects.
Level D - For extensions using objects that are explicitly not recommended.

The results of this structured analysis can then be uploaded to SAP Cloud ALM, populating the Clean Core Extensibility KPIs in the RISE with SAP Methodology Dashboard. Recently, the dashboard was enhanced with a display of the Clean Core Levels. This gives organizations a high-level, standardized view of their extensibility landscape, which is perfect for assessing their current situation and tracking progress. For the near future (Q1/2026) it is moreover planned to offer a deep dive dashboard that provides further details about the results.

What is "Project Kernseife"?

Project Kernseife is an open-source custom ATC Check for ABAP systems that enables you to flexibly score the usage of SAP objects in your system, e.g. to score the technical debt regarding clean core based on a custom, adjustable classification. More details on the parts and approach can be found in the blog "Project Kernseife - improving the measurement of Clean Core in ABAP".

Why Project Kernseife and its custom classification can be a Game-Changer for Clean Core Governance

Advantage 1: Fine-Tune SAP's Rules & Reduce "False Positives"

While SAP delivers thousands of released and classic APIs, it might still be not the perfect fit for your individual project and scope. Kernseife allows you to customly classify objects as "acceptable for your project", dramatically reducing noise and the need for mass ATC exemptions. Let's look into two different scenarios, to show you the benefits of custom classification:

Example 1: Stricter governance for direct table read

Within the standard classification, a direct read with a SELECT from any SAP table is considered as "Level C", which leads to warnings in ABAP Test Cockpit. In your project, you want to enforce the usage of ABAP cloud, you maybe have (see next point) identified many successor objects (custom and standard) and want to push developers to the successors objects (e.g., famous I_Product instead of MARA) by showing these as an error.
Remark: In standard ATC, you can adjust the priority of a check message in general (for example "Reading from DDIC database tables or DDIC table views is not recommended (successor available)", but not based on specific SAP objects you refer to.

Example 2: Need for usage of "internal object"

Now let's imagine you are working in a "clean core" project, but you need to extend processes around the Outbound Delivery Orders in EWM. After talking to experts, finding blog posts and even an "official" SAP Note, you identified the right interface: /SCWM/IF_API_WHR_OUTBOUND. Unfortunately, this is not yet listed as released or classic API. This would result in "warnings" in ATC and a classification as Level C ("Internal Objects" are used), although you did the best you can do. With Kernseife, you can now mark this SAP object as "recommended", which results in only "information" messages in ATC and leads to a "Level B" assessment of the custom code object / extension.

Based on these two examples, you can see: this is the power of a custom classification. You can overrule the SAP standard, be it because of timing (as you need the announced adjustments from the blog IMMEDIATELY) or scope (because SAP might not generally classify everything that you identify as "acceptable for your project" as "Classic API").

The possibility to "accept" usage of certain SAP objects will increase your governance quality, as your exemption approvers will not be flooded with hundreds of "false" exemption requests for objects that you generally accept in your project.

Advantage 2: Define and Enforce Custom Successors

While SAP is already delivering hundreds of the most important successor classifications (famous MARA -> I_Product), there might still be potential to guide your developers more precisely. Project Kernseife allows you to maintain a successor object in your classification, that will also be visible in the result of your ATC check - this makes it actionable for your developer!

Example 1: "Improve" Standard Successors

There are some more tables in the system, that have no successor mentioned officially, but where you can find (released!) CDS views as an alternative. To not flood you with details here, I simply refer to another blog based on the idea of @AndreasGraeber. But also for Function Modules or classes , there might be clear successors (e.g. not all READ_<table> might be having the successor information. There might be a lot of areas, where you want to decide in your project "don't use this, but use that!"

Example 2: Enforce and centralize Wrappers / custom successors

What happens if you create a wrapper for a standard SAP object, but your colleagues are not aware of it? They might re-create the same wrapper. With the possibility to also add Custom Objects (e.g. Z_WRAPPER_ABC) as a successor, you can also push your developers to harmonize the usage of wrappers.

Advantage 3: Enhance Dashboards for Measurement and Governance with consistent transparency

In several projects, we have already seen custom dashboards to track the current state of clean core. With the combination of the level concept and the "Technical Debt Score", you can assess systems and drill down into packages or even single objects.

Project Kernseife offers you direct access (e.g. with CDS-View ZKNSF_I_SCORING) to the data from ATC check runs to build these dashboards. You can use the Kernseife BTP Application to analyze your score - or create your own dashboard, for example with SAP Analytics Cloud, reflecting your custom rules to assign custom objects to business units (e.g. ZBR* is always Brasil).

The scoring is based on your configuration in the Kernseife classification, which allows you to own the definition of your clean core levels and deviate from SAP's standard definition - by this you own the definition of your clean core levels! To stick with the examples above, the usage of /SCWM/IF_API_WHR_OUTBOUND will impact your score in a limited way.

Advantage 4: Prioritize Your Cleanup Efforts with a "Potential Score"

After an analysis, you often face a daunting list of findings. The biggest challenge isn’t just identifying the issues, but knowing where to start the cleanup. This is where Kernseife's scoring mechanism becomes a powerful prioritization engine by providing two key metrics for each finding: a Score and a Potential Score.

The Score reflects the technical debt of the object as it exists today, based on your custom rules.
The Potential Score shows what the score would be if the developer refactored the code to use the defined successor.

Let's use our familiar example:

Your classification assigns a high "Technical Debt" Score of 10 for a direct SELECT on table MARA.
The officially released successor, I_Product, has a "clean" score of 0. Therefore, the finding's Potential Score is 0.

This creates a clear, quantifiable "improvement gap." An object with a Score of 10 and a Potential Score of 0 is a high-impact cleanup opportunity. In contrast, a finding with a Score of 2 and no defined successor (meaning its Potential Score is also 2) is a lower priority for immediate refactoring.

By sorting your findings based on the largest gap between the Score and Potential Score, you can instantly identify the "low-hanging fruits" and the refactoring tasks with the biggest impact. Let's be clear, this is just one piece of information, and maybe you shouldn't have any custom code in this area based on a process analysis, but I still believe it is important to have data to drive your decisions - and Project Kernseife offers you data for the technical insights.

Making the Right Choice: A Balanced Look at Both Approaches

Key Reasons to Adopt Project Kernseife

The main reason to use a Project Kernseife is typically the power of the custom classification (as the last chapter pointed out). You can adjust the classification of SAP objects based on your project reality and support your clean core journey with tailored data.

In addition, there might be a temporary, tactical benefit: As of today, Kernseife's dashboards can fill a gap until SAP's "Extensibility Deep Dive" dashboard is generally available.

Important Considerations: When the Standard Approach is a Better Fit

At the same time, I want to be very clear: Project Kernseife is not needed in every company and project.

1. The Need for Standard Alignment: If your primary goal is to align perfectly with SAP's out-of-the-box reporting and dashboards without deviation, the standard approach is more appropriate.
2. The Responsibility of Power: Custom classification is powerful, but it requires ownership. Someone must define, document, and maintain these custom rules. This is an ongoing responsibility (and effort!), which you can spare yourself when you go with the standard solution, i.e. RISE with SAP Methodology Dashboard.
3. Implementation and Maintenance Overhead: While straightforward for experienced teams, implementing and maintaining any non-standard solution requires effort that must be planned for. It is ironically against the clean core imperative of leveraging "standard"!
4. Unified Classification enables comparibility: Standardized classification leads to a comparability between different systems (e.g., you compare your central finance system with a peer system regarding the clean core level share), as the classification is the same for all systems.

Conclusion: Do you need to Take Control of Your Clean Core Strategy?

Project Kernseife is not for everyone. It is for organizations that find the standard clean core measurement too rigid and are ready to invest the effort to build a more nuanced, context-aware governance model. If you have the capacity and the architectural vision, it can transform your clean core initiative from a technical cleanup exercise into a strategic management of your system's extensibility.

Interested in more? Check out Project Kernseife: our open-source project where you can join the community, contribute, and support us with a GitHub star in the repository!