Clean core principles

Dimensions describe where clean core applies. Principles tell people what to do when they face a decision. A good set of principles is short, specific enough to settle arguments and written so that a developer, a process owner and a tester all understand it. This lesson builds Contoso's principles from SAP's guidance.

Standard first

The first principle is about processes, not code: adopt the standard unless there is a business reason not to. In SAP Activate this is the fit-to-standard approach, and SAP's clean core guidance asks for a standard-first mindset, few process variants and SAP Best Practices where they fit. Every gap that the standard closes is an extension nobody has to build, test or upgrade.

Released interfaces, at the highest level possible

When an extension is needed, it should use released interfaces. SAP's clean core level concept grades extensions: level A uses only publicly released, stable interfaces; level B also uses classic APIs that SAP documents as generally upgrade-stable; level C reaches into SAP internal objects for legacy scenarios; level D uses techniques SAP does not recommend, such as modifications, write access to SAP tables and implicit enhancements. SAP's guidance is to aim for A, accept B, use C only for specific needs, and avoid D. An extension is rated by its weakest component.

Integration and data principles

For integration, SAP's guidance is to use standard integration scenarios and released APIs published in the SAP Business Accelerator Hub, using OData, SOAP or events, and to make every integration monitorable with clear error handling. For data, the principle is completeness, correctness and compliance: avoid incomplete, corrupted and unused data, set data quality rules, fix violations promptly and keep monitoring.

Contoso's principles, as published

1. Standard first: a process variant needs a named business owner and a measurable benefit.
2. Extend at the highest clean core level possible; level D is not accepted for new work.
3. New ABAP code is written in ABAP Cloud unless the design authority approves an exception.
4. Interfaces use released APIs or events from the SAP Business Accelerator Hub; file interfaces need a reason.
5. Every interface and background job has a monitoring owner from day one.
6. Every extension has an owner, a clean core level, test cases and a retirement review date.
7. Master data has a data owner and quality rules; unused data is archived on a schedule.
8. The system stays current: stacks are applied on a planned rhythm, not when something breaks.

On-stack or side-by-side

Principles should also say where an extension lives. SAP describes three broad options: key user extensions built by business experts with low-code tools, developer extensions on-stack in ABAP Cloud when logic must sit close to the data and run in the same transaction, and side-by-side extensions on SAP BTP when an app needs its own lifecycle, other BTP services or data from several systems. Contoso's rule of thumb is simple: if the extension must validate or change an SAP document while it is being saved, it belongs on-stack; if it serves a different user group, combines data from several systems or changes on its own schedule, it belongs side-by-side. Both can be level A.