Lesson 5 of 5
Architecture review: assessing an extension design
10 min
Listen to this lesson
Everything in this course comes together in the architecture review: a structured look at a design before it is built and again before it goes live, against criteria agreed in advance. At Contoso the review board is small (the solution architect, Kenji for the S/4HANA side, Sam for the platform, Priya for testability), it meets every two weeks, and it reviews every new BTP extension and every significant change. This lesson walks through the review of the warranty app.
- SubmitThe team submits a short design: purpose, context diagram, dependency register, data flows, non-functional requirements
- Pre-readReviewers score the design against the criteria and note questions
- ReviewOne hour: open questions, risks, decisions; no redesign in the room
- DecideApprove, approve with conditions, or revise and resubmit
- RecordDecisions and conditions in an architecture decision record linked to the feature in SAP Cloud ALM
- VerifyConditions checked again before the go-live gate
The criteria
A review without written criteria becomes a debate of preferences. Contoso's criteria follow the lessons of this course, with a question and an expected answer for each.
| Area | Question | Expected answer |
|---|---|---|
| Stable dependencies | Is every dependency in the register with level, owner and covering tests? | Level A by default; any B or C justified, contained and dated |
| Data ownership | Which system owns each data object, and does the extension copy any? | S/4HANA stays the system of record; copies are caches with a stated freshness |
| Integration style | Events, APIs or both, and why? | Events for notifications; APIs for reads and commands; no polling loops |
| Resilience | Timeouts, retries, breakers and fallbacks per remote call? | Defined and testable, with labeled fallbacks |
| Security | Authentication, role collections, principal propagation, secrets? | Least privilege; no secrets in code or Git |
| Lifecycle | How are stacks, deprecations and runtime upgrades handled? | Triggers in the release calendar; contract tests exist |
| Operations | Logs, metrics, alerts, runbook, owners? | Symptom alerts with owners; correlated logs |
| Testability | Can each risk be tested in cmc-ext-test, including failures? | Test hooks and stage pairing defined |
| Delivery | MTA, pipeline, transport path, configuration per stage? | Same archive promoted; extension descriptors and destinations per stage |
Contoso's architecture review criteria.
Reviewing the warranty app
The warranty app lets fleet customers register alternator warranty claims. The first design reads sales and billing data through released APIs (good), subscribes to the agreementCreated business event of the core agreement RAP business object ZR_CMC_CoreAgreement (good), but also reads the internal pricing table through a custom RFC (Level C), stores a full copy of customer master data in SAP HANA Cloud "for speed", and has no fallback when S/4HANA is unavailable.
The board approved the design with conditions. The pricing read stays for the first release, isolated behind one adapter with contract tests and a register entry, with a replacement by a custom RAP-based service due before the next S/4HANA base release upgrade. The customer master copy is dropped: the app reads business partner data through the released API and caches only what it displays, with a stated freshness. Timeouts, a circuit breaker per destination and a labeled fallback are conditions for the go-live gate, with test evidence from cmc-ext-test.
Decisions that last
Each significant decision becomes an architecture decision record: the context, the options considered, the decision, its consequences and its review date. Records stop the same debate from recurring every time a new team member joins, and they tell a future upgrade team why a Level C dependency exists and when it was meant to go. Contoso links them to the feature in SAP Cloud ALM so they sit next to the requirements, tests and transports.
One more dimension appears only for some extensions: multitenancy. If an extension is ever offered to several companies (for example, Contoso offering the fleet portal to other distributors), tenant isolation, per-tenant configuration and onboarding become review criteria too. Contoso's extensions are single-tenant, and the review record says so explicitly, so nobody assumes otherwise later.
What would you do?
The warranty team argues that the architecture review is slowing them down and proposes skipping it "because the app only uses BTP, so it's clean core by definition". How should the solution architect respond?
- Architecture reviews use written criteria: dependencies, data, integration, resilience, security, lifecycle, operations, testability, delivery.
- Outcomes are approve, approve with conditions, or revise; conditions are verified at the go-live gate.
- Sort findings by risk and effort; high-risk items become conditions or redesigns.
- Architecture decision records keep context, options, decision and review date, linked in SAP Cloud ALM.
- Running on BTP does not make an extension clean core; its dependencies do.
Check your understanding · not graded
Lesson check
1. What should happen to a review condition at the go-live gate?
2. What does an architecture decision record capture?
3. A finding is high risk but low effort to fix. How should it be treated?
4. Why did the board drop the customer master copy in the warranty app?