Ask why an SAP upgrade is expensive and the answer is almost never the upgrade itself. It is the regression testing and remediation of everything that was bolted onto the core over the preceding decade. Clean core is the principle that addresses this directly.

The idea is simple to state and hard to hold: keep the standard core standard, and put your differentiating logic outside it, connected through released, versioned interfaces. When the core is upgraded, your extensions are insulated because they never reached inside.

What clean core actually asks of you

In practice the principle covers rather more than code. A genuinely clean core means extensibility through released APIs and extension points rather than modifications, integration through governed interfaces rather than direct table access, and data models that stay close to the standard so that standard functionality keeps working.

Clean core with governed extension points around a standard core

SAP has built tooling to support this, most visibly the restricted ABAP Cloud development model, which limits developers to released objects and public interfaces. The constraint feels uncomfortable at first. It is also precisely the point, because a rule that can be bypassed under deadline pressure is not a rule.

Where the discipline usually fails

  • A deadline arrives and a modification is faster than an extension, so an exception is granted and never revisited.
  • An integration reads directly from a standard table because the released API did not quite return the field somebody wanted.
  • Nobody owns the register of exceptions, so the accumulated debt is invisible until the next upgrade prices it.
  • Extension work is reviewed for whether it functions, but never for whether it complies.

Clean core is not a technical setting. It is a governance habit that has to survive contact with a deadline.

Making it stick

The organisations that hold the line tend to do three unglamorous things. They define what compliant extensibility means in their own context and write it down. They review extension designs against that definition before development starts, not after. And they keep a visible register of every exception, with an owner and a remediation date attached.

None of that requires new software. It requires someone with the authority to say no, and a business sponsor who understands that today’s shortcut is a line item in the next upgrade budget.

Leave a Reply

Your email address will not be published. Required fields are marked *