Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 5 of 5

Governance dashboard

9 min

Listen to this lesson

0:00 / 14:34

Clean core is a direction, not a state. Every new requirement is a chance to extend cleanly or to add technical debt, and every release is a test of how much debt there is. A governance dashboard makes the direction visible to the people who decide: the architecture board, the PMO and the business owners who fund remediation. SAP itself points to dashboard-style insight into clean core adoption for RISE customers; whatever tool you use, the measures below are what make the conversation concrete.

What to measure

MeasureSourceWhy it matters
Extension inventory by clean core level (A–D), trend per releaseATC clean core check results; extension registerThe main driver of upgrade effort
Inventory by business criticality and ownerExtension register, process ownersWhere risk meets value; who decides
Developer test coverage of changed objectsABAP Unit and pipeline resultsWhether logic is protected cheaply
Open ATC findings and exemptions, with age and expiryATCDebt being added or paid down
Contract test status per APIPipelineBoundary health of side-by-side apps
Upgrade findings: objects adjusted, defects found in regression, escaped defectsUpgrade project records, SAP Cloud ALMWhat clean core actually saved or cost
Unused custom codeUsage data and custom code analysisCandidates to retire rather than test

A clean core quality dashboard for Contoso.

Steering viewTrend of levels A–D, upgrade effort per release, top risks and funding asks
Architecture board viewNew extensions by level, exemptions, remediation progress
Delivery viewATC findings, test coverage, contract status per team and per release
Data sourcesATC, ABAP Unit, pipelines, extension register, SAP Cloud ALM test results
One dataset, three audiences. Each view answers the question its audience owns.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-402

Keep the data collection boring and automatic. ATC results can be run on a schedule across all custom packages, pipeline results already exist for every build, and SAP Cloud ALM holds regression results and defects per release. The extension register is the one manual piece: a list of extensions with owner, business process, criticality and clean core level, updated by the architecture board when it approves a change. If the dashboard needs a person to assemble it each month, it will stop being updated within a quarter.

The extension register is the hub of the dashboard: ATC, tests, exemptions and upgrade findings all hang off each extension.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-402

Making it drive decisions

A dashboard nobody acts on is decoration. Tie each view to a decision. The architecture board approves any new level C or D extension with a reason and a remediation plan. The steering committee funds remediation of critical level C and D objects using the upgrade effort they cause as the business case. Delivery teams can't close a release with expired exemptions. And after each upgrade, compare predicted with actual effort by level: if level A extensions really did need almost no work, that evidence wins the next funding argument.

Tying the dashboard to decisions means every new level C or D extension needs a reason and a remediation plan before it is built.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-402
  1. Go-liveBaselineInventory by level and criticality recorded after the conversion
  2. First feature pack stackMeasure upgrade effortEffort and defects by level; first remediation candidates
  3. Following quartersRemediate the critical fewRebuild top level D/C objects on released APIs with unit tests
  4. Next major releaseCompareEffort per object by level; adjust targets and funding
A realistic clean core path for a converted system. Not everything gets cleaned; the critical few do.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-402

Pitfalls

  • Counting objects, not risk: 300 unused level C reports matter less than one critical modification.
  • Coverage theater: a high unit-test percentage on trivial code while critical logic is untested.
  • Exemptions as permanent state: an exemption list that only grows.
  • Ignoring side-by-side: BTP apps are clean by design but still fail at their contracts.
  • No link to upgrade reality: if the dashboard never shows actual upgrade effort, it can't prove its value.

What would you do?

The steering committee asks why it should fund clean core remediation when "the system works." What evidence should Priya bring from the dashboard?

Key points
  • Track extensions by clean core level, criticality and owner, with trends per release.
  • Include test coverage, ATC findings and exemptions, contract status and actual upgrade effort.
  • Give each audience a view tied to a decision: approval, funding or release closure.
  • Remediate the critical few, and prove the benefit by comparing upgrade effort before and after.

Check your understanding · not graded

Lesson check

  1. 1. Which measure best links clean core to cost?

  2. 2. What should happen to a new level D extension request?

  3. 3. Which is a dashboard pitfall?