Lesson 2 of 5
Decision framework
9 min
Listen to this lesson
With the dead code gone, Contoso still has 193 extensions to decide on. Treating each as a fresh debate would take years. A decision framework gives every extension the same questions and a small set of outcomes, so that architects, process owners and the board can agree quickly and revisit decisions when facts change.
The five outcomes
| Outcome | What it means | Typical trigger | Contoso example |
|---|---|---|---|
| Retire | Delete the extension | No usage, or the business no longer needs it | Custom report Z_MARGIN_DAILY, replaced by a standard analytical app |
| Replace with standard | Switch to SAP standard functionality and delete the custom code | The standard now covers the need | A custom output routine replaced by standard output management |
| Refactor in place | Improve structure, performance and level without changing behavior | Logic is sound and valuable, but the code is hard to test or uses internal objects | Z_FLEET_REBATE_CALC: interface, pushdown, released or classic APIs |
| Wrap | Isolate a dependency on unreleased SAP objects behind a small wrapper so new code can be ABAP Cloud | No released API exists yet, but new logic should be clean | Wrapper for an unreleased pricing function used by new fleet logic |
| Rebuild | Re-create the capability with RAP and ABAP Cloud on-stack, or side-by-side on SAP BTP | The design no longer fits, or the old code is level D in a critical process | Core return agreement maintenance rebuilt as a draft-enabled RAP app |
Five outcomes. Every extension gets exactly one, with a reason and an owner.
The questions, in order
- Is it used, or needed for a rare critical purpose?No → retire · Yes → next question
- Does SAP standard now cover the need well enough?Yes → replace with standard · No → next question
- Is the logic sound and the design still a fit?Yes → refactor in place (wrap where a dependency has no released API) · No → next question
- Is it critical, high-risk (level C or D) or blocking upgrades?Yes → rebuild, in slices · No → leave as is for now, with regression coverage
Note the last branch. "Leave as is for now" is a legitimate outcome for a level B or C extension that works, rarely changes and is covered by regression tests. Modernization budgets are finite; spending them on stable, low-risk code delays work that matters.
Weighing refactor against rebuild
The hardest calls sit between refactoring and rebuilding. Refactoring keeps the behavior the business relies on and changes structure in small, testable steps. Rebuilding gives a clean design but must rediscover every rule the old code implements, including the undocumented ones. A rebuild that misses a rule is a production defect. Favor refactoring when the logic is right and the problem is structure; favor rebuilding when the design is wrong, the technology is a dead end, or the code is so entangled that safe small steps are impossible.
| Factor | Refactor in place | Rebuild |
|---|---|---|
| Behavior risk | Low, if characterization tests pin current behavior | Higher: every rule must be rediscovered and reimplemented |
| Clean core gain | Step by step, often to level B or C first | Can reach level A in one move |
| Delivery | Small slices that ride along with feature work | A project with its own plan, parallel run and cutover |
| Best when | Logic is valuable, structure is the problem | Design or technology no longer fits, or level D in a critical flow |
Rebuild without a big bang
Martin Fowler's strangler fig pattern describes how to replace a legacy system gradually: build the new capability alongside the old one, move behavior across piece by piece, and retire the old code once nothing depends on it. In SAP terms, a new RAP app and its released APIs can take over one part of a process (for example, creating new core return agreements) while the old transaction still handles changes to existing ones, until the new app covers everything. The temporary code that lets both coexist is a planned cost, not waste.
What would you do?
The legacy function module Z_FLEET_REBATE_CALC has complex, well-understood rebate rules that Dan's team trusts, but it reads SAP pricing tables directly (level C), is slow, and has no tests. A developer wants to rebuild it from scratch as a RAP business object. What should Kenji decide?
- Five outcomes: retire, replace with standard, refactor in place, wrap, rebuild; plus "leave as is with tests".
- Ask the same questions in order: used? standard? logic sound? critical or high-risk?
- Refactor when logic is valuable and structure is the problem; rebuild when design or technology no longer fits.
- Rebuild gradually with the strangler fig pattern; temporary coexistence code is a planned cost.
Check your understanding · not graded
Lesson check
1. Which outcome fits an extension the standard now covers well enough?
2. When is rebuilding favored over refactoring?
3. What does the strangler fig pattern describe?
4. Is "leave as is for now" a valid outcome?