Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 1 of 5

Clean core dimensions

10 min

Listen to this lesson

0:00 / 4:55

"Clean core" is often heard as "no custom code". That reading is too narrow, and it leads architects to fight the wrong battles. SAP describes a clean core as a system that is up to date, transparent, unmodified, consistent, efficient and cloud compliant, and it spreads that idea across several dimensions of the ERP landscape. Custom code is one of them. Processes, integrations, data and the way the system is operated matter just as much.

Six dimensions, sometimes counted as five

SAP Learning content on the clean core concept lists six dimensions: software stack and core, processes, extensibility, integration, data and operations. Other SAP material groups them into five by leaving out the software stack. The count is not important; covering all of them is.

Software stack and coreStay current: follow the release strategy instead of freezing on an old release
ProcessesStandard first: few variants, SAP Best Practices where they fit, documented processes
ExtensibilityUpgrade-stable extensions built with SAP's extensibility model and released interfaces
IntegrationStandard integration content and released APIs (OData, SOAP, events), monitored with clear error handling
DataComplete, correct and compliant data; no corrupted or unused data piling up
OperationsSolution documentation, test management, a security concept without unused authorizations, managed batch jobs
The clean core dimensions as described in SAP Learning content. Each needs an owner.
The Sign-Off Table · thesignofftable.com/academy/sap-arc-201

What each dimension looks like at Contoso

DimensionContoso today (ECC 6.0 EHP 8)Clean core target in SAP S/4HANA
Software stackSeveral years behind on support packagesSAP S/4HANA 2025, with a planned rhythm of stacks
ProcessesThree local variants of order to cashOne standard order to cash, variants only where Maria can show business value
ExtensibilityAbout 11,800 custom objects, some modificationsUnused code retired; remaining code rated and moved toward levels A and B
IntegrationPoint-to-point file interfaces, IDocs with custom segmentsReleased APIs and events through SAP Integration Suite, monitored
DataDuplicate customers and blocked materials never archivedCleansed master data and quality rules with owners
OperationsUnused roles, unmonitored jobs, test cases in spreadsheetsRoles reviewed, jobs monitored, tests and documentation in SAP Cloud ALM

Contoso's clean core gap by dimension.

The table shows why "clean core" is a program-wide concern. Dan, the finance process owner, owns part of the process dimension. Sam owns much of operations. Kenji owns extensibility. The integration team owns integration. If the architect treats clean core as Kenji's problem alone, half of the gap is ignored.

Clean core has an owner per dimension; treating it as the developers' problem leaves most of the gap unowned.
The Sign-Off Table · thesignofftable.com/academy/sap-arc-201

Clean core in a system conversion

A conversion is the cheapest moment to clean up, because every object is touched anyway. Contoso uses it in three ways. First, the conversion forces custom code adaptation for SAP S/4HANA simplifications, so Kenji's team rates each object's clean core level while it is open. Second, usage data from production shows which objects nobody runs, and those are retired instead of converted. Third, the conversion resets the software stack to SAP S/4HANA 2025, so the stack dimension starts clean. What a conversion does not fix by itself are processes, data quality and operations habits: those carry over unchanged unless someone owns them. That is why the architect writes a target for every dimension into the program charter, not just a custom code target.

The conversion is the cheapest moment to clean up: usage data retires unused code before anyone converts it.
The Sign-Off Table · thesignofftable.com/academy/sap-arc-201

Clean core is not "no custom code"

SAP's own guidance says to add extensions where they create measurable differentiation, built on-stack or side-by-side with released APIs and strong governance. A company that differentiates on its core return program for fleet customers should build that capability; it should build it in a way the next upgrade does not break. The opposite mistake also exists: rebuilding a standard function as custom code because "ours is slightly different" creates cost without differentiation.

RemoveCustom code that copies the standard and breaks at upgrades. Retire or replace with standard
Rebuild cleanlyDifferentiating, but built on internals or modifications. Move to released interfaces
Use standardCommodity processes done the standard way. Leave them alone
InvestDifferentiating and upgrade-stable. This is where custom work belongs
Sorting extensions by differentiation and stability.
The Sign-Off Table · thesignofftable.com/academy/sap-arc-201

What would you do?

In a kickoff, a project manager says: "Clean core is handled; Kenji's team is removing custom code." As the architect, what should you say?

Key points
  • SAP describes clean core across six dimensions: software stack, processes, extensibility, integration, data and operations.
  • Each dimension needs an owner; extensibility is only one of them.
  • Clean core allows differentiating extensions that are built to survive upgrades.
  • Assess an object across every dimension it touches, not just its code.

Check your understanding · not graded

Lesson check

  1. 1. Which list matches the clean core dimensions in SAP Learning content?

  2. 2. Which statement about clean core and custom code is accurate?

  3. 3. Which item belongs to the operations dimension?

  4. 4. Why can an interface built on a released API still fall short of clean core?