Clean Core Fails at the Decision Level

As of October 2026 · David Riederich

Many SAP Clean Core initiatives begin with the technical surface: custom code, modifications, extensions, interfaces and upgrade readiness. That is understandable. These things are visible. But in most organizations, they are not the root cause. They are the outcome of decisions that were never properly structured.

Clean Core is not primarily a technical cleanup exercise. It is a discipline for deciding when to stay standard, when to extend, and when an exception is worth the long-term consequences.

The Common Misunderstanding

Clean Core is often interpreted as a technical principle: reduce custom code, avoid modifications, use SAP BTP, keep the core clean.

None of this is wrong. But it is incomplete.

A system does not become complex because one developer writes one enhancement. It becomes complex when many local exceptions, urgent workarounds and undocumented deviations accumulate over time.

The decisive question is therefore not only:

“How do we reduce custom code?”

The better question is:

“Why do we keep producing the decisions that create custom code?”

Custom Code Is Often the Symptom

Custom code is rarely created in isolation. In many SAP landscapes, it is the technical expression of organizational patterns.

Typical examples are:

• local business exceptions that slowly become permanent
• historical process variants that no one wants to challenge
• requirements approved under time pressure without architectural review
• unclear ownership between business, IT and implementation partners
• temporary workarounds that remain in the system for years
• interfaces built because no one wanted to decide on a common process

In these cases, the technical artifact is real. But the cause is not technical. The cause is a missing decision structure.

Four Decisions That Pollute the Core

From a Clean Core perspective, the most relevant decisions are usually not large architecture decisions made once per program. They are recurring decisions that appear harmless in the moment.

1. The Local Exception

A plant, sales organization, company code or region needs a specific deviation. The business case may be understandable. But without a clear evaluation of long-term consequences, the exception becomes part of the permanent system logic.

One exception is rarely the problem. Ten exceptions across different locations become an operating model.

2. The Urgent Workaround

A project is under pressure. A go-live is approaching. A defect must be solved quickly. The workaround is accepted because it helps the project move forward.

The risk is not the workaround itself. The risk is that no one owns the decision to remove, redesign or govern it afterwards.

3. The Politically Accepted Deviation

Some deviations are not technical decisions at all. They are political compromises. A stakeholder wants a specific process, a partner proposes a pragmatic solution, and the architecture impact is accepted without being made explicit.

This is where Clean Core often fails quietly: not because no one knew better, but because no one had the mandate to say no.

4. The Operational Small Change

Many Clean Core risks emerge after go-live, when small operational changes are approved without the same scrutiny as project decisions. A local field, a workflow adjustment or a small extension may look harmless, but over time these changes can reintroduce the very complexity the transformation tried to remove.

The issue is not the size of the change. The issue is that operational changes often bypass the architectural attention they deserve.

Why BTP Does Not Solve the Governance Problem

SAP BTP can be a powerful part of a Clean Core strategy. It allows extensions to be built outside the digital core and can reduce the need for direct modifications.

But moving complexity out of the core does not automatically make it disappear. Poorly governed extensions are still complexity. They are simply located somewhere else.

A bad decision implemented on BTP remains a bad decision. It may be cleaner from an upgrade perspective, but it can still create integration debt, unclear ownership and operational risk.

Clean Core therefore requires more than a technical extension strategy. It requires a decision model for when an extension is justified, who owns it, how it is operated and what consequences it creates.

The Clean Core Decision Filter

Before approving a deviation from the standard, organizations should be able to answer a few simple questions.

1. What problem are we really solving?

Many requirements describe a preferred solution, not the actual problem. Clean Core requires separating business need from implementation preference.

2. Is the standard genuinely insufficient?

Fit-to-standard does not mean accepting every SAP standard blindly. But it does mean that deviations must be justified, not assumed.

3. What is the long-term cost of the deviation?

Every deviation has a lifecycle: build, test, document, operate, upgrade, monitor and eventually replace. If these costs are not visible, the decision is incomplete.

4. Who owns the decision after go-live?

If no one owns the deviation after go-live, the organization has not made an architecture decision. It has created future ambiguity.

5. What would make us remove it again?

A deviation without an exit condition tends to become permanent. Clean Core discipline means defining not only why something is created, but also under which conditions it should be challenged again.

What Clean Core Governance Looks Like in Practice

Effective Clean Core governance does not need to be bureaucratic. In many organizations, a few practical mechanisms already make a significant difference.

• A clear deviation policy: what may enter the core, what belongs outside, and what should not be built at all.
• An impact assessment: a short evaluation of operational, architectural, integration and upgrade consequences.
• Decision ownership: clear accountability for approving and maintaining deviations.
• Architecture review routines: recurring review of extensions, interfaces and variants.
• A variant register: transparency over local deviations and their business justification.

The goal is not to slow down projects. The goal is to prevent small decisions from creating large long-term consequences.

Clean Core Requires the Right Kind of Discipline

Discipline does not mean saying no to every requirement. It means making the trade-off explicit.

Some deviations are justified. Some extensions are necessary. Some business requirements cannot be solved meaningfully through standard functionality.

The problem begins when these decisions are made without a common evaluation logic. Then every project, location or partner decides differently. Over time, the SAP landscape becomes a collection of local decisions rather than a coherent system.

Clean Core is not the absence of extensions. It is the presence of disciplined decisions.

What Organizations Should Avoid

Three misconceptions repeatedly weaken Clean Core initiatives.

• “Less code means less complexity.”
  Less code helps, but complexity can also live in integrations, processes, data flows and unclear ownership.
• “BTP automatically makes us Clean Core.”
  BTP can protect the core, but it does not replace architecture, governance or operational responsibility.
• “The standard always wins.”
  Standard should be the default, not a dogma. The important point is that deviations must be consciously justified.

Conclusion: Clean Core Is Decision Quality

Clean Core does not fail because organizations lack technical options. It fails when decisions about requirements, exceptions, extensions and variants are made without sufficient structure.

ABAP, BTP, interfaces and extensions are visible. Decision quality is less visible. But it is usually the deciding factor.

Organizations that treat Clean Core as a governance and architecture discipline create SAP landscapes that are easier to upgrade, easier to operate and easier to change.

Clean Core is not code hygiene. It is a way of making SAP decisions responsibly.

Frequently Asked Questions About SAP Clean Core

What does Clean Core mean in the SAP context?

Clean Core means keeping the SAP digital core stable, upgradeable and close to standard. In practice, this requires clear governance, architectural guardrails and disciplined handling of extensions and deviations.

Is Clean Core mainly about reducing custom code?

No. Reducing custom code is one visible part of Clean Core, but not the whole concept. The more important question is how requirements, exceptions and extensions are evaluated before they become technical artifacts.

What role does SAP BTP play in Clean Core?

SAP BTP can help keep extensions outside the core. However, BTP does not replace governance. Extensions still require ownership, architecture review, operational responsibility and a clear reason to exist.

How should a company start a Clean Core initiative?

A practical starting point is to assess existing custom code, extensions, interfaces and variants, then define decision criteria for future deviations. The first step is not only cleanup, but a better decision model.

Back to Insights