Architect / Cross-trackAdvanced

SAP Clean Core Governance: Standards, ATC and Documentation (Part 9)

Key takeaway

Sustain Clean Core after go-live with an extension inventory, released-API checks, ATC quality gates, named owners, exception records and periodic review of upgrade-sensitive dependencies.

Explanation

Clean Core is a continuing governance model, not a one-time conversion activity. Even a clean S/4HANA landscape can drift back toward tightly coupled custom code if new projects introduce direct table dependencies, unreleased APIs or undocumented source-level enhancements.

Maintain an extension inventory that records the custom object, business purpose, technical owner, business owner, extension type, consumed SAP APIs, ATC status, risk level and review date. This makes upgrade planning evidence-based instead of rediscovering custom logic during every release cycle.

Use ATC and released-object checks as quality gates for new development. Findings should be reviewed according to severity and deployment model. Where a non-released dependency is temporarily unavoidable, create a formal exception with justification, owner, mitigation and review or expiry date rather than silently suppressing the finding.

Architecture review should focus on dependency quality. A small enhancement that reads internal SAP persistence can be more upgrade-sensitive than a larger side-by-side application that consumes released APIs and events.

Measure governance outcomes such as new high-risk dependencies, overdue exceptions, unused custom objects and remediation progress. The goal is sustainable changeability, not a vanity metric such as zero Z objects.

Code example

ABAP Code

"Example governance record"Object          : ZCL_SD_ORDER_VALIDATOR"Business owner  : Sales Operations"Technical owner : ABAP Platform Team"Extension type  : Released BAdI + service class"Released APIs   : Yes"ATC status      : No blocking findings"Risk            : Medium"Review date     : Before next release upgrade

Real project scenario

A company completed an S/4 migration with strict clean-core rules, but two years later dozens of new direct-table integrations had appeared. Adding transport ATC gates and an exception register prevented further drift and exposed the existing remediation backlog.

Common mistakes

Treating Clean Core as a project milestone only.
Tracking custom objects without ownership.
Suppressing ATC findings permanently.
Measuring only custom-object count.
Having no review date for exceptions.

Best practices

Maintain one extension inventory.
Put released-API checks into delivery governance.
Assign business and technical owners.
Time-limit exceptions.
Review high-risk dependencies before each upgrade cycle.

Interview angle

Explain how you keep a landscape clean after go-live. A strong answer should include inventory, ATC gates, ownership, exceptions and periodic review.

Practice this lesson

Quick check

1. In the lesson "Clean Core Governance and Documentation", consider this project situation: A company completed an S/4 migration with strict clean-core rules, but two years later dozens of new direct-table integrations had appeared. Which statement is correct?

2. Why are unreleased SAP objects risky in custom code?

3. What is the main goal of Clean Core?

Interview questions

1. How do you sustain Clean Core after go-live?

Answer it in your own words first, then compare.

2. Using this SAP project situation — A company completed an S/4 migration with strict clean-core rules, but two years later dozens of new direct-table integrations had appeared — explain Clean Core Governance and Documentation. What should happen, which concepts or process steps matter, and what common mistake would you avoid?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.