Lesson 2 of 5
Trade-offs
10 min
Listen to this lesson
Every architecture option is a bundle of trade-offs. A side-by-side extension isolates custom code from upgrades but adds an integration to build, run and test. A system conversion keeps history and custom code but carries old data quality and old design into the new system. The job is not to find an option without downsides; it is to make the downsides visible, compare them honestly and choose the ones the business can live with.
Make quality and test impact a criterion
Programs routinely compare options on license cost, implementation effort and time. Fewer compare them on what each option costs in validation, then and for years after. That is a mistake, because architecture choices set the regression scope of every future change. In SAP S/4HANA Cloud Private Edition, SAP's learning material describes a base release every two years with Feature Pack Stacks about every six months, and states that testing is the customer's or partner's responsibility. An option that doubles the regression effort of each upgrade costs that much again at every one.
| Option | Upgrade impact | Test impact per release | Other trade-offs |
|---|---|---|---|
| Classic custom code with modifications | High: modifications and internal objects can break | Broad regression of affected processes every upgrade | Fastest to build; highest technical debt |
| On-stack ABAP Cloud using released APIs | Low: released APIs carry stability commitments | Focused: unit tests plus targeted process tests | Needs released APIs for the use case; skills |
| Side-by-side on SAP BTP | Low for the core; separate BTP lifecycle | Interface and contract tests plus BTP release testing | Extra platform, integration and operations |
| Standard process, no extension | Lowest | Standard regression only | Business must accept the standard |
Clean core levels as a trade-off scale
SAP published a four-level clean core model in 2025. Level A is fully compliant: extensions use only public, stable SAP interfaces, on-stack with ABAP Cloud or side-by-side on SAP BTP. Level B adds SAP's classic APIs, which are documented and generally upgrade-stable. Level C accesses internal SAP objects for legacy scenarios; SAP's changelog for SAP objects is the input for checking them before each upgrade. Level D, not recommended, relies on modifications, direct writes to SAP tables or implicit enhancements, and carries the highest risk. The levels map almost directly to test impact: the further down, the more each upgrade must be retested.
Beyond functionality
Test impact is one quality consequence among several. Each option also shifts performance (an extra network hop for a side-by-side extension), security (another platform with its own users, roles and patching), operations (another component to monitor and support) and data consistency (copies that can drift). Name these explicitly in the comparison, even when they cannot be scored precisely. A short line per option, such as "adds one interface to monitor and one platform to patch", is enough to stop them from being forgotten.
Comparing options with numbers
Put rough numbers on the comparison. For each option, estimate build effort, run cost and the test effort per release over five or more years. Weighted scoring helps when criteria do not share a unit, but keep weights visible and agreed. Sensitivity matters more than precision: if the winning option changes when a weight moves slightly, the decision is close and deserves more evidence or a prototype.
| Criterion (weight) | Keep classic custom table and code | Rebuild on-stack with ABAP Cloud | Rebuild side-by-side on BTP |
|---|---|---|---|
| Build effort (20%) | 5: already exists | 3 | 2 |
| Upgrade and test effort over 5 years (30%) | 1: retest every upgrade | 4 | 4 |
| Integration complexity (15%) | 5: none | 5: none | 2: new interface |
| Business fit (25%) | 4 | 4 | 4 |
| Skills available (10%) | 5 | 3 | 2 |
| Weighted score | 3.55 | 3.85 | 3.1 |
Illustrative weighted scoring for Contoso's core return agreements (scale 1 to 5; higher is better). Numbers are examples, not benchmarks.
What would you do?
A team argues that an extension option is "free" because it reuses existing ECC custom code, and objects to counting test effort because "testing is the test team's budget". What should the architect do?
- Make trade-offs visible; no option is free of downsides.
- Count quality and test impact over years, because releases and feature packs keep coming.
- Clean core levels A to D are also a scale of upgrade and regression risk.
- Use rough numbers and visible weights; check sensitivity before declaring a winner.
Check your understanding · not graded
Lesson check
1. Why include test impact in architecture trade-offs?
2. Which clean core level relies on modifications or direct writes to SAP tables?
3. What does a sensitivity check on weighted scoring reveal?
4. Which extension option usually adds integration testing to every release?