For years, the architectural conversation around SAP S/4HANA seemed trapped in a rigid side.
On one side, the purist vision moving all development to side-by-side extensibility on SAP BTP. On the other side, the operational reality, where complex transactional logic and proximity to data made decoupling code technically expensive and sometimes unfeasible..
However, we often lost in this conversation: Clean Core… what’s side-by-side… what’s On-stack
Not so far back in time, we followed the 3-Tier Development Model. This framework tried to organize development into three tiers (Tier 1 for Cloud, Tier 2 with Wrappers, Tier 3 for Legacy).
While useful, there’s a new pragmatic second generation framework: the Clean Core Level Concept
This new maturity model increases the availability of APIs and reduces the forced need for wrappers, incorporating classic ABAP use cases safely. But how does this translate into the modern architecture of Levels A, B, C, and D?
Level A: The Gold Standard (On-stack & Side-by-side)
Level A doesn’t force you off-stack. It represents extensions that rely exclusively on stable, public interfaces backed by stability. Is agnostic to the deployment environment:
Side-by-side Extensions: Decoupled extensions running on the Business Technology Platform. This ecosystem allows for SAP Build (low-code/pro-code), CAP (Java/Node.js), and ABAP Cloud (Steampunk) to create scalable apps and automations
On-stack Extensions: Created inside SAP S/4HANA Cloud (either as Key User Extensions or Developer Extensions). This validates that building tightly coupled logic within the S/4HANA it’s ok, provided that released technologies like RAP (RESTful ABAP Programming) and CDS Views are used. So that by using of released APIs and strict syntax checks, you can build tightly coupled logic (essential for transactional integrity) without creating technical debt
Level B: The Pragmatism of “Classic APIs”
Unlike Level A, which relies on stability contracts, Level B uses Classic APIs and frameworks. While not strictly “Cloud” capable, these are nominated by SAP product experts as upgrade-stable.
You can identify these in the Cloudification Repository. Object frameworks such as SAPscript, and ALE/IDoc integrations fall into this category. This provides a critical “safe harbor,” allowing to leverage proven legacy technologies without facing immediate refactoring pressure
Level C: Risk Management and Changelogs
When business reality demands the use of internal SAP objects for legacy scenarios, we enter Level C. Unlike the previous levels, there is an upgrade risk here. To mitigate it, SAP provides the Changelog for SAP Objects, a tool that allows you to identify incompatible changes early and plan proactive actions. Although not the preferred approach, it is a valid option if managed with wrappers to isolate the dependency.
Level D : The red line (Technical Debt)
Any extension that uses non-recommended techniques, such as direct modifications to the standard, direct writing to tables, or Implicit Enhancements, falls into this category. This represents the highest risk of technical debt and must be rigorously blocked using ABAP Test Cockpit (ATC) checks. These patterns bypass standard logic and guarantee disruption during upgrades
Extensions objects are classified as unfit for customer use (marked as “noAPI” in the Cloudification Repository)
By understanding Levels (A, B, C, D) we can make architectural decisions that balance technical purity with operational reality, prioritizing business stability and flexibility…. But Important!!: Beyond the levels, a Clean Core strategy requires governance. The fundamental principle is: Extensions must be avoided when possible. Before, we must to evaluate if standard functionality covers the process. If the extension is inevitable, we must ensure that extensions don’t break Upgrades
To decide between an On-stack or Side-by-side implementation, customers should use the SAP Application Extension Methodology. This methodology helps to define a custom extension strategy. It addresses challenges like “clean core” by offering a structured, standard approach. This ensures a common understanding and terminology and it allows to assess technical options and make informed decisions to build an extension framework for your organization.
—
Bookmark this SAP Note: 3578329 – Frameworks, Technologies and Development Patterns in Context of Clean Core Extensibility
Official list of framework and technology classifications that will tell you what is Level A, B, C, or D
New Cloudification Repository Viewer for Clean Core Governance and Development
https://community.sap.com/t5/technology-blog-posts-by-sap/new-cloudification-repository-viewer-for-clean-core-governance-and/ba-p/14236110
For years, the architectural conversation around SAP S/4HANA seemed trapped in a rigid side.On one side, the purist vision moving all development to side-by-side extensibility on SAP BTP. On the other side, the operational reality, where complex transactional logic and proximity to data made decoupling code technically expensive and sometimes unfeasible..However, we often lost in this conversation: Clean Core… what’s side-by-side… what’s On-stackNot so far back in time, we followed the 3-Tier Development Model. This framework tried to organize development into three tiers (Tier 1 for Cloud, Tier 2 with Wrappers, Tier 3 for Legacy).While useful, there’s a new pragmatic second generation framework: the Clean Core Level ConceptThis new maturity model increases the availability of APIs and reduces the forced need for wrappers, incorporating classic ABAP use cases safely. But how does this translate into the modern architecture of Levels A, B, C, and D?Level A: The Gold Standard (On-stack & Side-by-side)Level A doesn’t force you off-stack. It represents extensions that rely exclusively on stable, public interfaces backed by stability. Is agnostic to the deployment environment:Side-by-side Extensions: Decoupled extensions running on the Business Technology Platform. This ecosystem allows for SAP Build (low-code/pro-code), CAP (Java/Node.js), and ABAP Cloud (Steampunk) to create scalable apps and automationsOn-stack Extensions: Created inside SAP S/4HANA Cloud (either as Key User Extensions or Developer Extensions). This validates that building tightly coupled logic within the S/4HANA it’s ok, provided that released technologies like RAP (RESTful ABAP Programming) and CDS Views are used. So that by using of released APIs and strict syntax checks, you can build tightly coupled logic (essential for transactional integrity) without creating technical debtLevel B: The Pragmatism of “Classic APIs”Unlike Level A, which relies on stability contracts, Level B uses Classic APIs and frameworks. While not strictly “Cloud” capable, these are nominated by SAP product experts as upgrade-stable.You can identify these in the Cloudification Repository. Object frameworks such as SAPscript, and ALE/IDoc integrations fall into this category. This provides a critical “safe harbor,” allowing to leverage proven legacy technologies without facing immediate refactoring pressureLevel C: Risk Management and ChangelogsWhen business reality demands the use of internal SAP objects for legacy scenarios, we enter Level C. Unlike the previous levels, there is an upgrade risk here. To mitigate it, SAP provides the Changelog for SAP Objects, a tool that allows you to identify incompatible changes early and plan proactive actions. Although not the preferred approach, it is a valid option if managed with wrappers to isolate the dependency.Level D : The red line (Technical Debt)Any extension that uses non-recommended techniques, such as direct modifications to the standard, direct writing to tables, or Implicit Enhancements, falls into this category. This represents the highest risk of technical debt and must be rigorously blocked using ABAP Test Cockpit (ATC) checks. These patterns bypass standard logic and guarantee disruption during upgradesExtensions objects are classified as unfit for customer use (marked as “noAPI” in the Cloudification Repository) By understanding Levels (A, B, C, D) we can make architectural decisions that balance technical purity with operational reality, prioritizing business stability and flexibility…. But Important!!: Beyond the levels, a Clean Core strategy requires governance. The fundamental principle is: Extensions must be avoided when possible. Before, we must to evaluate if standard functionality covers the process. If the extension is inevitable, we must ensure that extensions don’t break UpgradesTo decide between an On-stack or Side-by-side implementation, customers should use the SAP Application Extension Methodology. This methodology helps to define a custom extension strategy. It addresses challenges like “clean core” by offering a structured, standard approach. This ensures a common understanding and terminology and it allows to assess technical options and make informed decisions to build an extension framework for your organization.—Bookmark this SAP Note: 3578329 – Frameworks, Technologies and Development Patterns in Context of Clean Core Extensibility Official list of framework and technology classifications that will tell you what is Level A, B, C, or DNew Cloudification Repository Viewer for Clean Core Governance and Developmenthttps://community.sap.com/t5/technology-blog-posts-by-sap/new-cloudification-repository-viewer-for-clean-core-governance-and/ba-p/14236110 Read More Technology Blog Posts by SAP articles
#SAP
#SAPTechnologyblog
