Data Boundaries, Security, and Governance for Clean Core Extensions

Explanation

Clean Core is ultimately an access-control and governance discipline as much as a coding style. Once an organization agrees to avoid core modification, the harder ongoing work is enforcing that no team quietly reintroduces tight coupling through undisclosed table access, unreleased API usage, or ad hoc database views. This lesson focuses on the data, security, and governance mechanisms an architect must put in place to make Clean Core durable rather than a one-time migration slogan. Data access boundary: the core principle is that any extension, whether in-app or side-by-side, must read and write only through released interfaces - released CDS views, released BAdIs, and released APIs (OData V2/V4, SOAP, or REST as published in the API Business Hub or equivalent released catalog). Unreleased objects can change or disappear across upgrades without notice, and direct table access bypasses business logic such as authorization checks, derivations, and consistency rules embedded in the application layer. In S/4HANA Public Cloud this is enforced at the platform level - unreleased objects are simply not accessible from the extensibility framework. In private cloud and on-premise, enforcement is largely a governance and code-review responsibility, since the ABAP stack technically still permits direct access; architects must rely on static code checks, custom code migration tooling categorization (released vs not released, or deprecated), and CI/CD quality gates to catch violations before they reach production. Security model: side-by-side extensions on BTP introduce a distinct security surface. Authentication typically uses OAuth2, with client credentials for system-to-system calls and principal propagation when an extension must act on behalf of an end user (so the core's own authorization checks still apply based on that user's roles, rather than a blanket service account bypassing segregation-of-duties controls). Architects must decide, per integration, whether principal propagation is required for compliance reasons (e.g., approval workflows where SoD matters) versus where a technical service user with tightly scoped authorizations is acceptable (e.g., a read-only reporting extract). Secrets and credentials for these connections should be stored in a managed credential store rather than embedded in extension code, and API scopes should be minimized to only the operations the extension actually needs - broad admin-level API grants are a common audit finding. Governance for durability: a Clean Core governance model typically includes (1) a custom code register that classifies every extension by tier (in-app key-user, in-app developer/RAP, side-by-side) and by the released interfaces it depends on; (2) an architecture review gate that any new extension must pass before development, verifying no direct table or unreleased object access is planned; (3) automated static checks integrated into the transport or CI/CD pipeline that flag unreleased API usage, direct table access, or deprecated object references before code can be transported to production; (4) a recurring review cadence (e.g., before each SAP release upgrade) that re-scans existing custom code against the current released-object catalog, since objects can be deprecated or reclassified over time; (5) clear ownership - a named team or role accountable for approving exceptions when a genuinely unavoidable deviation from clean core is required, with an explicit expiry or remediation plan rather than a permanent waiver. Migration and rollback implications: when migrating custom code from ECC, the SAP-provided custom code migration analysis (as part of the broader system conversion tooling) classifies existing objects by their compatibility with S/4HANA and, separately, by their clean core compliance. Objects using obsolete data structures or direct table access to now-restructured tables must be remediated, not merely technically adjusted. Rollback planning for a clean core extension is generally simpler than for core modifications: because the extension lives in its own namespace (in-app) or its own system (side-by-side), rollback often means deactivating or undeploying the extension without needing to revert core transports, which is a genuine operational advantage of the approach - but only if the governance controls above were actually followed, since exceptions and hidden coupling erode this benefit.

Code example

-- Governance static-check pseudo-rule (illustrative, not a real SAP tool syntax)-- Rule: FLAG any extension object referencing a table or CDS view-- that is not present in the RELEASED_OBJECTS catalog CHECK_RULE clean_core_data_access:  FOR EACH custom_object IN transport_request:    IF custom_object.references NOT IN released_objects_catalog:      RAISE governance_violation(        object = custom_object.name,        reason = 'Access to unreleased or direct table object'      )    ENDIF  ENDFOR * OAuth2 principal propagation concept (illustrative)* Side-by-side BTP app calls core API using the end user's token,* not a shared service account, so core authorization checks still applyGET /released/api/salesordersAuthorization: Bearer <user_propagated_token>

Real project scenario

An architecture review during a private cloud rollout discovered that a side-by-side BTP extension had been using a technical service account with broad authorizations to call an internal, unreleased API endpoint because the released equivalent lacked one required field. The governance board required the team to log a formal exception with a remediation deadline tied to an upcoming SAP release that was expected to add the missing field to the released API, and mandated switching to principal propagation in the interim to preserve segregation-of-duties controls for approval-sensitive data.

Common mistakes

• Allowing side-by-side extensions to use a single broad-scope service account instead of principal propagation for user-sensitive operations • Treating custom code migration classification as a one-time exercise instead of re-checking before every major release upgrade • Granting permanent waivers for clean core exceptions instead of tracking them with remediation deadlines • Skipping static code checks in the CI/CD pipeline, relying only on manual code review which misses unreleased object usage • Storing API credentials or secrets directly in extension code or configuration files instead of a managed credential store

Best practices

• Enforce released-object-only access through automated static checks in the transport or CI/CD pipeline, not manual review alone • Use principal propagation for extensions touching approval or SoD-sensitive data; reserve service accounts for narrowly scoped technical operations • Maintain a custom code and extension register classifying every object by extensibility tier and released dependencies • Track any clean core exceptions with an explicit owner and remediation deadline rather than a permanent waiver • Re-run custom code compliance analysis before every major release upgrade, since released object catalogs evolve

Interview angle

Senior and architect-level interviews often test whether a candidate treats clean core as sustained governance rather than a migration checkbox. Strong answers describe concrete controls: a custom code register, CI/CD static checks against a released-object catalog, principal propagation versus service accounts, and a recurring re-validation cadence tied to release upgrades. Weak answers stop at 'use only released APIs' without describing how that is enforced and audited over time.