Introduction
As mentioned in the last blog of this series, we defined our own Clean Core Index. Clean Core Index is a KPI to measure our Clean Core compliance. A Clean Core Index of 0 means, our system is 100% Clean Core compliant and can be run in a public cloud scenario.
The Clean Core Index is one of the most important aspect in our Clean Core strategy. For details about our strategy, please refer to the previous blog entry of this series.
Please note, the Clean Core Index explained here is our company-specific definition. There is no official definition available (at least I'm not aware of). Our Clean Core Index definition definitely doesn't cover all aspects and even if the index will be 0, our system we will not be able to run in a public cloud for sure.
Nonetheless, it helps us to get a better understanding of how clean our core is as well as were we can improve.
Last but not least, managers typically have limited knowledge and understanding about technology and software development. The might not be able to follow when you're talking about importance of Clean Core Strategy and your progress. But they love figures and you will get their attention, if you provide figures to them.
Clean Core Index, definition
First we define all object types, which are relevant for us. Then we added a severity (factor) to each object type together with a reason for the severity.
Ours looks like this
| Type | Severity | Reason |
| Reports | 1 | High effort needed for redesign, no cost savings |
| Function Modules | 1 | High effort needed for redesign, no cost savings |
| SAPScript + Smartforms | 2 | Obsolete since 20 years, high effort for redesign, low risk but seriously outdated. Should be replaced each time one asks for a change on such a form |
| ATC Errors (S/4 readiness check) | 5 | Easy to handle, doesn‘t influence upgrade processes. Exists because we became lazy |
| User Exits without released BAdI as successor | 5 | No alternative available, should be verified after each upgrade 1) |
| User Exits with released BAdI as successor | 8 | Low effort for redesign, high risk during upgrade 1) |
| Modifications | 10 | High risk, high effort during upgrade |
| Impl. Enhancements | 10 | High risk, high effort during upgrade |
We now determine the count per object type and multiply this with the corresponding severity. Voila, your Clean Core Index has been calculated.
Some notes about ATC errors. During our conversion from ECC to S/4, we had to deal with all ATC errors resulting from S/4 HANA Readiness check. We solved all Priority 1 findings. When we started with our Clean Core Strategy, we noticed that again there were ATC prio 1 findings. Didn't we solve all of them during our migration? There are two reasons
- S/4 readiness check evolves also. We use latest available, which now includes checks which were not available during our migration
- We became lazy. We once agreed to run ATC for any kind of development but people stopped to do this. They developed like they did before resulting in new ATC findings.
Some notes about User-Exits. Most User-Exits have been replaced by a BAdI but some still have not been replaced. There is no way to distinguish between those. Instead, each User-Exit needs to be checked manually. I wasn't aware of this at the beginning and therefore defined different severities. Now, each User-Exit gets handled with severity of 8.
Clean Core Index, how to measure
To measure the Clean Core Index, several CDS Views have been developed. You find everything in this git repository.
https://github.com/sap-weberpatrick/Clean-Core-Index
UPL SAPScript
Special note about usage statistics for SAPScript and SmartForms. It is not that straight forward to identify, if a form is in use or not. For this, I developed my own report which runs periodically. Results are stored in a dedicated Z-Table. You find this report and class as well inside of the git repository.
Clean Core Index, initial figures
Conclusion
By measuring the index regularly, like once per week, we can track our progress. We're also able to track progress by module (MM, PP, SD,…) as well as by type (modification, ATC, reports).