SAP architecture, development, and transformation teams turning clean-core principles into a repeatable operating control.
How to move beyond a one-time clean-core score and maintain traceable decisions across releases, extensions, custom code, interfaces, and approved exceptions.
Decision context
Clean core is an ongoing method, not a badge produced by one scan. A useful system must identify the observed extension or dependency, explain the rule, distinguish evidence from inference, record the chosen treatment, and detect when a later snapshot reintroduces drift.
Adranum combines ATC and readiness findings, custom-code dependencies, architecture context, requirements, and policy decisions. It produces a transparent score with interpretable factors, but the score never replaces the underlying findings or imply official SAP certification.
Teams can preserve an exception with an owner and rationale, remediate a supported pattern, replace behavior with a target extension, or retire unused code. Repeat snapshots compare newly introduced, resolved, and persistent findings so clean core becomes an accountable release practice.
What the workflow must cover
- Transparent assessment. Show finding severity, rule, affected object, dependency context, source coverage, and score contribution. Missing evidence reduces confidence instead of improving the score.
- Disposition governance. Record keep, replace, remediate, or retire decisions with owners, rationale, policy checks, and approval history.
- Release-to-release drift. Compare snapshots to identify new violations, changed dependencies, reopened risks, and exceptions whose review period expired.
- Evidence export. Export source hashes, finding state, decisions, diffs, validation boundaries, approvals, and control mappings for technical and procurement review.
Implementation workflow
Start with a bounded customer scenario and explicit acceptance criteria. Preserve native SAP permissions and accountable review while the software creates a repeatable evidence chain.
- Collect supported custom-code and readiness evidence.
- Review scan coverage before interpreting the score.
- Assign treatments, owners, and exception expiries.
- Generate and validate supported remediation.
- Repeat the snapshot and investigate new or persistent drift.
Evidence to require
A transformation claim should resolve to observable artifacts, decisions, and execution receipts. Ask for the following evidence in a representative evaluation:
- Coverage denominator
- Rule and finding version
- Object dependencies
- Score factor
- Disposition history
- Exception owner and expiry
- Remediation validation state
- Snapshot comparison
Boundaries and non-claims
Adranum separates analysis, proposal, human review, package creation, customer-local validation, and production execution. A later state never rewrites the evidence that supported an earlier decision.
- Adranum does not issue an official SAP clean-core certification.
- A clean score is bounded by supplied artifacts and observed connectors.
- Architecture decisions and production release remain customer responsibilities.
Buyer checklist
- Is the score formula interpretable?
- Are missing objects included in the coverage denominator?
- Can exceptions expire and be re-reviewed?
- Does the system distinguish proposal from SAP validation?
- Can teams compare drift between releases?