Exploring How to Make Extensions Clean Core Compliant

Many customers have historically embedded custom features directly into the SAP core, which can function effectively at first. However, they may create complications during upgrades if SAP alters its standard functions. Addressing these issues often entails considerable time and cost. The effort required is influenced by not only the type of extension but also its interaction with SAP functionality. Surprisingly, even minor or seemingly simple changes can become significant barriers to upgrades. SAP Cloud ERP being designed from the ground up as a cloud native product requires a structured extensibility approach to ensure that upgrades to the product happen smoothly with no disruptions. Clean core extensibility ensures that this is the case.

An adoption of the clean core extensibility principle results in the following advantages:

• Simplification of the update process due to the decoupling of customer and SAP code thus enabling the faster adoption of innovation.

• Reduction of technical debt and increased transparency resulting in greater flexibility.

• Shortening of the design-build-deploy process enabling faster time-to-market.

• An advanced extensibility framework: Both on-stack and side-by-side with SAP BTP deployment options each of which is supported end to end by both low-code and pro-code development tooling.

The main characteristics of a clean extension revolve around two pillars:

• Leveraging Released APIs
• Adherence To The SAP S/4HANA Cloud Extensibility Model

A "released API" is simply any ABAP development repository artifact (i.e., data element, CDS view, ABAP Class) that has been "released" by SAP. The release ensures safety, consistency and stability of the artifact across upgrade cycles and is thus equally safe, consistent and stable for customers to use. While in some situations using a "non-released API" may be utilized (see the "Clean Core Level Concept" which will be discussed in a moment) released APIs are always the preferred choice if available.

The SAP S/4HANA Cloud Extensibility Model categorizes extensions as either "on-stack" (running on SAP S/4HANA) or "side-by-side" (running on SAP BTP). Side-by-side is preferred (keeping the core clean) however certain use cases (e.g., a BADI on SAP Cloud ERP) require a local implementation.

By ensuring that added modules or extensions operate independently of the core's intricate details, this principle aims to prevent tight coupling and dependencies. This separation allows both the core and extensions to evolve independently, minimizing the risks of unintended impacts on functionality. As result SAP Cloud ERP is stable, simple, and upgrade-friendly. It remains modification free and new features can be added in a straightforward and transparent way.

Having covered what is considered a clean extensions let's now explore how to get there. The approach to ensuring clean extensions revolves around three goals:

• Creating decoupled extensions to ensure upgrade stability - by leveraging released APIs from SAP.
• Ensure continuous governance from requirement to design through implementation to deployment.
• Ensure technical debt is always an informed decision - and manage it professionally.

The first goal we have already discussed extensively. Making sure extensions are decoupled by utilizing released APIs whenever possible.

The second goal concerns governance. In the journey towards clean core extensibility, it is crucial to implement continuous governance for new extensions. This involves evaluating functional requests to determine if they can be managed using standard features or add-ons, and assessing their innovation or differentiation potential. Once the business value is established, extension architecture should be carefully planned using consistent methodologies, followed by a stringent approval process based on architecture choices, such as on-stack or side-by-side implementations. Effective documentation of decisions regarding architecture, approvals, and technical debt is essential.

For extension implementation, development guidelines must be adhered to, with automated code checks ensuring compliance. Access restrictions based on experience levels can help maintain high standard practices, while changes require re-evaluation through documented approval processes. During deployment, mandatory code checks on transport release safeguard against unintended technical debt, with lead developers managing exemptions. Consistent housekeeping and monitoring in both greenfield and brownfield scenarios are vital, keeping an eye on expected outcomes and tracking technical debt. By setting realistic goals and adhering to standards, businesses can progressively achieve cleaner codebases, supporting a sustainable clean core strategy.

The third goal concerns technical debt. The definition of technical debt is fairly straightforward:

• Technical debt refers to any customization that deviates from the standard, upgrade-stable SAP codebase and architecture, thereby potentially increasing the complexity and cost of future maintenance and innovation.

Technical debt comes in several forms:

• Modifications to SAP Standard Code
• Clones of Standard Programs (these programs no longer receive updated from SAP)
• Old-School Enhancements (Tightly-Coupled):
• • User Exits
  • Classic BAdIs
  • Implicit Enhancements

Managing technical debt requires a balanced approach, ensuring informed decisions that are professionally documented and managed. New technical debts should remain limited and well-justified, keeping in mind the need for governance that does not overwhelm the development process but prevents reliance on outdated methods. Organizations must measure technical debt, setting ambitious yet realistic goals to mitigate it, recognizing that legacy code will not disappear overnight. Regular reviews or set time limits can help manage technical debt validity, while adopting a governance model suited to the organizational context—be it lean in small, tightly managed teams or more structured in large settings with numerous external developers. Implementing a KPI framework to measure progress enables organizations to set goals, providing incentives for reducing technical debt and enhancing developer motivation. Even minor cleanup activities can significantly lower debt scores, promoting a cleaner codebase and fostering an environment conducive to continuous improvement.

A suggested framework for organizations to follow to manage technical debt could revolve around the following:

Requirement: Begin by verifying if the required functionality can be achieved using standard SAP features. Customers have the option to check SAP Best Practices content, which offers detailed examples and guidance on how standard functionalities meet business needs. If extensions are necessary, ensure they add significant business value and offer a competitive edge. Establishing a Solution Standardization Board can help validate the necessity and strategic importance of any proposed extension.

Design: Develop clear guidelines to ensure the most efficient design choices. Utilize resources like the SAP Application Extension Methodology to determine the sequence and criteria for selecting optimal technical solutions. Create technology maps and guidance that align with SAP Best Practices and system constraints, using levels of recommendation—such as Level A & Level B and so on to guide architecture decisions.

Implementation: Foster a culture where developers pursue the clean core approach and transparently document technical debt. Provide time for developer training and certification, such as Acquiring Core ABAP Skills as well as Developing with SAP Build – From Apps to Automation and encourage the use of no-code or low-code options.

Deployment: Implement mandatory code checks using the ABAP Test Cockpit, complemented by a structured exemption process. Document the approval workflow, including who grants exemptions and what control samples are evaluated. This ensures consistent quality and reduces risks during deployment.

For every new extension, you should follow this process of continuous governance. This is a MUST for every greenfield project, to put a strong focus on governance. But even for brownfield, in future all "net-new" developments should follow this governance cycle:

We've talked a lot about how important released APIs are in achieving clean core extensibility. For customers using SAP Cloud ERP released APIs are their only option. However for customers using SAP Cloud ERP Private and on-premise ERP while released API's are still encouraged to be used certain non released APIs are considered to be "safe enough" that their usage is permitted. This pragmatic flexibility is necessary for these customers as their ERP systems contain custom code that require access to these non released APIs. To ensure alliance with the aforementioned goals of governance and transparency a "level approach" has been developed by SAP and is used by customers. The levels are A through D in order of advisability or suggestion. Briefly summarized they are:

• Level A:

  Usage is solely based on released APIs. This is the ideal, "cleanest" level for extensions built within the ERP system. It is fully compliant with the clean core strategy and guarantees upgrade stability. As just mentioned this is the only level permitted for SAP Cloud ERP.

• Level B:

  This level is for developments that utilize "classic APIs". Classic APIs are artifacts that are considered "safe" (i.e., highly unlikely to change on an upgrade) and while not officially "released" are nonetheless safe to be used.

• Level C:

  This level is for developments that utilize artifacts that might carry some risk if the artifact were to change. To reduce upgrade risk, SAP provides a changelog for these objects so organizations can identify incompatible changes early and plan their upgrades accordingly

• Level D:

  This level is for developments that are not considered "clean" because they use explicitly non-recommended artifacts or techniques.

Customers are encouraged to utilize APIs in levels A - C ( in that order of preference ). So for example if an ABAP Class were created which utilized two released APIs (level A) and one classic API (level B) then the ABAP Class as a whole would be considered "Level B" clean core compliant.