Introduction

In this second blog about Clean Core I want to show you our Clean Core strategy. If you don't know what Clean Core means or if you're interested in where we came from please refer to the first blog of this series.

Background

End of last year, I came to the conclusion that we need to clean up our core by reducing our technical debts. Also we need to ensure to keep it clean and to avoid any new development, which is not Clean Core compliant (as often as possible)

In sum, we need some strategy and guideline. I spent several months in reading about Clean Core and found many, many resources which explains the term, theoretically. Everything makes sense but it was hard to find some practical approach.

I want to share our approach with you hoping to give some impressions to enable you to create your own vision and strategy. I'm also highly interested in your meanings and ideas which might help us to improve our own strategy.

Clean Core Strategy

Measure and Scoping

Before we start to clean up, we need to get a clear picture of the mess. You need to be aware of any custom code object.

• Get an overview of all modified objects
• Get a list of all user-exits, BAdIs etc. you implemented
• Which custom reports are available and are they still in use?
• Same is true for print forms (SAPScript, SmartForms)
• Which objects you're responsible for and which will not be part of your activities? For example, we use some abapgit repositories (Excel integration, MS Graph), which might violate Clean Core principles. If you still need them, will it be your task to fix this?

To measure this, we introduced a new KPI for us, the Clean Core Index. The Clean Core Index measures how clean our core is. The lower the value, the better. A Clean Core Index of 0 means, we're 100% Clean Core compliant.

The Clean Core Index is a collection of different measurements, like amount of modifications, reports, forms and others. I'm a developer and I'm lazy, meaning I don't want to do this in Excel manually. Instead, we developed a collection of CDS views to measure and track our progress.

There will be a separate blog about what we measure and how we do that.

We also use SAP standard technologies for our Custom Code Lifecycle Management, like SCMON and Usage and Procedure Logging (UPL). Also we use Custom Code Migration App as well as CCLM of Solution Manager. There is no 100% fit solution available for us. Each solution has its own limitations and drawbacks, but we try to take as much of each solution as possible.

Create awareness in Business and Management

Explain the importance of Clean Core to your Board of Management as well as to your customers in business departments. At the beginning, time you spend in Clean Core activities will not create measurable benefits for your company. Your BoM will need to know, why you have to spend your time in Clean Core activities without creating business value.

Same is true for your customers. They're familiar with their good old processes and custom transaction. They might have used those since more than 10 years and they're afraid in learning new things.

Be prepared for these hurdles. Create some training material to explain what Clean Core means, why it is important and engage your colleagues to participate

Here some arguments from the first blog, which helps especially with the BoM:

• reduce cost for system maintenance because of reduced time
• reduced training effort for new joiners. Business colleagues with SAP skills will be more valuable in a system with no or few modifications
• reduced costs when acting with external partners
• Speed up your development by using SAP standard whenever possible

Development Guidelines and Governances

Hopefully, you already defined a development guideline which describes the rules of how you develop in SAP. This guideline might be outdated as it mostly describes how you did in past in ECC system. At least our guideline didn't cover S/4 development objects and paradigm, like rules for CDS Views, RESTful ABAP, when to use which technology and so on.

Also create a strong governance and processes to ensure informed decisions. In past, developers modified the system without any approval. Often it was easier and faster for them to modify instead of looking for alternatives. This leads to thousands (yes, I mean more than 1000) modifications in our system, often without any documentation.
To avoid this, each modification must now be approved by Head of IT first.

Quality Gates

Even if the entire team agreed on rules and guidelines, they're human beings. Meaning they will fail to follow the principles in all cases and they will become lazy. To ensure good code quality and guideline, define some quality gates. These gates must be passed successfully before deploying into productive environments.

1. First of all, we defined our own ABAP Test Cockpit (ATC) check variant. It is based on S/4 HANA Readiness check plus some additions.
2. Install ATC checks for ABAP code-PAL. We don't use all of them but some are pretty handy.
3. We activated automated ATC checks when releasing a transport request. Now it is mandatory to pass ATC successfully.
4. We implemented BAdI for transport request creation to prevent developers from creating or releasing a TR of type Repair.
5. We developed our own ATC checks
   1. There is a ATC check for ABAPDoc comments in classes available in standard. It creates a warning by default, if ABAPDoc is missing. We could change this severity to error but this will lead to the need to adding ABAPDoc to all existing classes. To increase acceptance of developers, we build our own ATC check for ABAPDoc. It will create an error only if a class has been created after a certain date. For each newly created class, ABAPDoc becomes mandatory but changing a class created 10 years ago, there is (actually) no need to add ABAPDoc as well.
   2. To ensure proper documentation of modified objects (in rare case there is no alternative and it has been approved), there is a custom ATC check which look up for documentation to ensure it is available. A modification without documentation will not be moved to productive environment by this
6. Other ATC check ideas not finalized so far
   1. Ensures a Knowledge Transfer Document (KTD) has been created for each object possible (CDS View, RAP API)
   2. Ensures documentation of custom Fiori App is available in our custom Fiori App Reference library (yes, we introduced our own)
   3. Ensures documentation of CDS Views, RAP APIs, Classes and others is available in our custom api repository (again yes, we introduced our own like api.sap.com)

Engage

Define a learning journey for each member of your team, individually. Ensure to get all of them familiar with S/4 development and your principles. We introduced our own communication channel in MS Teams, which can be taken like a community. All team members are encouraged to post about their latest learning and share their knowledge

Today we almost use none of the product available in SAP BTP, like SAP Build Apps, ABAP Cloud platform, Integration suite, Translation Hub, you name it.

To get familiar with the products available and to find use-cases for us, each team member investigates in one product analyzing how to use it and which benefit it brings for our company. We do this not only to get familiar with these products but also get the colleagues out of their comfort zone and to broaden their scope.

Other dimension

As explained in first blog of this series, Clean Core is not only code but also other dimensions. We simply started with development as we found this will add the most benefit for us. Based on our learnings and fails, other teams started to create their own Clean Core strategy by, again

• Measuring and defining the scope
• Define their Clean Core Index
• Define Quality gates
• Engage the colleagues

Define targets

You will not be able to renovate 30 years of legacy code within weeks. Clean Core is a journey of several months or few years. Therefore, it is crucial to define targets and steps based on your vision. What do you want to achieve in 6 months? What do you want to achieve after 12 months?

Define realistic targets and define also how to measure your progress. Share your results on a regular basis (we do it on a quarterly basis) with your entire IT team as well as your management and organization

Spoiler alert: the targets were too ambitious.

Short term targets (6 months)

• Prevent modifications
• Activate mandatory ATC checks during release of transport request
• Use Eclipse with ADT only (some still stick to SE80 or even SE38)
• Use ABAPCleaner in Eclipse
• Train development team in RESTful ABAP and Fiori Elements
• Train development team in Key-User Extensibility framework
• Explore SAP BTP solutions
• And most important for me, bring Clean Core Index down to a defined value (<15.000 in our case)

Mid-term targets (12 months)

• ABAP code-PAL as mandatory ATC check
• Alter ABAP language version to ABAP Cloud for any object possible
• Stop and prevent developing of custom reports
• Introduce new communication channels for knowledge transfer
• Analysis of other dimensions by Consultants
• Explore even more SAP BTP solutions
• Refine development guideline by adding use cases and design patterns
• Resolve all ATC errors (S/4 HANA Readiness check)

Long-term targets (18 months)

• Evaluate any tier-3 enhancement (classical ABAP) for relevance, alternatives, available documentation and business reason.
• Migration of all user-exits into BAdI
• Migration of all SAPScript and SmartForms to Adobe Forms

Development Artifacts and their Clean Core Compliance

After talking so long about vision and strategy, you as a developer still ask, which development artifact is Clean Core compliant and which alternatives are available.

To my understanding, the following table shows development artifacts which are not Clean Core compliant and which technology should be used as alternative

Development artifact not compliant	Compliant alternatives
Modifications	None
User-Exits	Released BAdIs
Duplicates of SAP objects	None
Implicit enhancements	None
Method overriding of SAP standard classes	None
Business Transaction Events (BTE)	Business Object Events, RAP Events
SAPScript and SmartForms	Adobe Forms
Queries (SQ01/SQ02, Quick views)	Analytical CDS views, consumed by analytical Fiori apps or Excel
Z-Reports and custom function modules	RAP API consumed by Fiori or SAP Build apps
Batch-Input in Z-reports	SAP standard API and Business Objects (api.sap.com)

You may wonder about custom reports. They're not Clean Core compliant as, to my best knowledge, you can't develop a custom ABAP report in public cloud. There is also no SAP GUI available. As an alternative, you need to develop Fiori or SAPUI5 apps. SAP Build apps might be also a good alternative.

Sounds good so far? There is one drawback. If you're running on-premise, you define your jobs in SM36/SM37. As job step you only can define ABAP Reports. It is not possible to call a class method, for example. Actually this is the onliest valid use-case for developing a custom report for us.

Conclusion

By writing this, we're in month 8 of our Clean Core journey. We achieved almost all of our short term targets, some were delayed but all were feasible. But we discovered that some of the mid-term and long-term targets might not be feasible at all.

ABAP Code-PAL and ABAP language version ensures to only use officially released objects. I once ran an ATC job with ABAP code-PAL variant. This leads to more than 2.4 million ATC errors as we're using almost no released objects. Or at least, SAP only released few objects compared to what have been used during the past 30 years.

Same is true for ABAP language version. If you change the version of a class, you might need to handle hundreds of errors telling you're using a non-released object. But often there is no alternative available. I can't imagine how much effort is needed to define all the missing but common data elements by your own for public cloud scenario.

We wanted to stop development of custom reports but as already said, sometimes there is no alternative, like for background jobs

We planned to replace all User-Exits by corresponding BAdI. Surprisingly, sometimes it is not possible as no BAdI has been provided so far. We will replace as many user-exits as possible but we can't get rid of all of them.

Migration of forms from SAPScript to Adobe Forms seems also to be a challenging task. Some forms (i.e., purchase orders) are complex and available templates doesn't meet our requirements. I noticed that most of my colleagues are not familiar with developing forms in general. This needs to be addressed in their personal learning journey first. Also it is not easy to identify, if a certain form is still in use or not. We found a solution for SAPScript and SmartForms, more in one of the next blogs.

Evaluating SAP BTP is also not that easy for us. We can make use of trial accounts but not all products are available or only with limited capabilities. For example, we tried to use Translation Hub to translate our existing ABAP texts (text literals, selection screens etc.) into foreign languages. This is possible in general but not in a trial account. The company I'm working for gets owned by an even larger company and we get our licenses by their company agreement with SAP. Often it is not easy to get a clear picture of what has been licensed, what we're allowed to use and what they will charge to us.

Beside these hurdles, we made great progress in reducing our Clean Core Index. The total amount of modifications and reports was reduced dramatically and all ATC findings have been solved so far. Due to our regular announcements about our progress, we get even more support from our business colleagues and management. Both helps us to improve even further.

In the next blog of this series will explain how we define and measure our Clean Core Index