Lesson 1 of 5
Decision framing
10 min
Listen to this lesson
An SAP transformation is shaped by a small number of decisions made early: where the system runs, how the program gets from ECC to S/4HANA, how the business will extend standard software, how systems will be integrated and where data and analytics will live. Each of these decisions sets costs and risks for a decade. Most programs make them under time pressure, with incomplete facts and strong opinions. This course is about making them well, recording them so others can understand them, and changing them when the facts change.
Which decisions are architecturally significant
| Decision area | Typical options | Why it is hard to reverse |
|---|---|---|
| Deployment | SAP S/4HANA Cloud Public Edition; Private Edition under RISE with SAP; on-premise | Sets the upgrade rhythm, extension rules, operations model and contract |
| Transition path | New implementation; system conversion; selective data transition | Decides what history, custom code and configuration survive |
| Extension strategy | On-stack with ABAP Cloud or classic ABAP; side-by-side on SAP BTP; key user tools | Determines upgrade effort and test scope for every future release |
| Integration strategy | Integration platform, patterns, event use, API governance | Every interface built afterward follows it |
| Data and analytics | Embedded analytics; data platform; data ownership model | Reports, KPIs and data products accumulate on top of it |
The major architecture decision areas in an SAP transformation.
A useful test for significance: a decision is architecturally significant if reversing it later would cost a lot, would affect many teams, or would change the program's risk profile. Choosing a naming convention for custom CDS views is not; choosing whether custom logic runs on-stack or on SAP BTP is.
Framing before choosing
Bad decisions usually start with bad framing: a solution presented as a question ("should we use BTP?"), a single option dressed up with straw men, or criteria invented after the preferred answer. A well-framed decision has six parts.
- ProblemWhat must be decided, by when, and why now
- Drivers and constraintsBusiness goals, deadlines, budget, regulation, existing contracts, skills
- OptionsAt least three real options, including "defer" or "keep as is" where valid
- CriteriaAgreed before scoring: cost, risk, time, fit, quality and test impact, reversibility
- EvaluationEach option scored against criteria with evidence, not opinion
- Decision and ownerWho decides, who is consulted, and when it will be reviewed
Reversibility and timing
Some decisions are one-way doors: once you have converted the production system or signed a five-year contract, going back is impractical. Others are two-way: an interface pattern for one flow can be changed in the next release. Spend effort in proportion. For one-way decisions, gather evidence, prototype and involve the people who will live with the result. For two-way decisions, decide quickly and record the assumption so it can be revisited. Make each decision at the last responsible moment: late enough to have the facts, early enough that the program does not stall waiting for it.
Framing traps in SAP programs
- The vendor frame. The question arrives shaped by a product pitch: "which BTP service should we use?" before anyone has said what problem needs solving.
- The precedent frame. "We did it this way in ECC" treats the old design as a requirement rather than as one option.
- The deadline frame. Time pressure collapses options to the fastest one, without recording what the shortcut costs later.
- The silo frame. One team frames a decision that changes another team's work, such as an extension choice that doubles integration testing.
Who decides
Major decisions need a named decision owner and clear consultation. Typically the solution architect proposes and documents; an architecture board or design authority reviews; the program sponsor or steering committee decides where cost, contract or business impact is large. Test leadership belongs in consultation for every major decision, because every one of them changes what must be tested and how often.
What would you do?
The program director asks the architects to "confirm that we should build all extensions on SAP BTP" in a one-page memo by Friday. What should the lead architect do?
- Significant decisions are costly to reverse, affect many teams or change risk.
- Frame first: problem, drivers, constraints, three real options, criteria agreed before scoring.
- Match effort to reversibility and impact; decide at the last responsible moment.
- Name a decision owner; consult test leadership on every major decision.
Check your understanding · not graded
Lesson check
1. Which is an architecturally significant decision?
2. When should decision criteria be agreed?
3. How much effort does an easy-to-reverse, low-impact decision deserve?
4. Why consult test leadership on major architecture decisions?