TL;DR

RISE with SAP can change the operating model of an SAP landscape.

Clean Core can protect the system-of-record from uncontrolled modification.

SAP BTP can provide the extension foundation.

But none of them automatically answers the harder architectural question:

Is your SAP BTP extension architecture structurally safe to evolve?

That question still requires judgment.

RISE may move the core into a cleaner operating model. Clean Core may preserve the anchor. BTP may provide the right extension platform.

But your extension landscape still has to prove:

• identity continuity
• tenant boundary correctness
• data ownership discipline
• integration contract stability
• lifecycle reconstructibility

This article explains why RISE does not remove the need for architecture judgment.

In many cases, it makes that judgment more important.

Preface — The Dangerous Comfort After RISE

RISE gives many organizations a sense of direction.

The core is moving toward a cleaner operating model. The transformation journey becomes more structured. Clean Core becomes a visible objective. BTP becomes the natural place for side-by-side extensions.

This is progress.

But progress creates a dangerous assumption:

“If we are moving to RISE, following Clean Core, and building extensions on BTP, then our architecture direction must already be safe.”

Not necessarily.

That assumption confuses three different things:

• operating model
• core cleanliness
• extension architecture

They are related.

They are not the same.

RISE can reshape how the core is operated. Clean Core can protect what the core should remain. BTP can provide the substrate for extensions.

But none of them automatically decides whether your extension landscape can survive real lifecycle change.

That is where architectural judgment begins.

1. RISE Changes the Operating Model — Not the Extension Boundary Model

RISE is often discussed through the language of transformation:

• cloud transition
• modernization
• standardization
• cleaner operations
• faster innovation
• future readiness

These are important.

But BTP extension architecture lives at a different layer.

A side-by-side extension does not fail merely because the core is hosted differently.

It fails when the extension boundary model is wrong:

• identity is not preserved across the real chain
• tenant context is assumed instead of designed
• replicated data becomes shadow truth
• integration is treated as endpoint connectivity
• lifecycle operations are not reconstructible
• ownership is split by component while no one owns the chain

RISE may improve the landscape context.

It does not automatically design these boundaries.

That distinction matters.

Because many of the most expensive extension failures happen after the organization believes it has already chosen the right strategic direction.

The strategic direction may be correct.

The extension architecture may still be invalid.

2. Clean Core Is the Anchor — Not the Whole Architecture

Clean Core is essential.

Without a clean core, the enterprise system gradually loses its stable anchor:

• business truth fragments
• integration semantics drift
• extensions inherit undocumented deviations
• upgrades become conditional
• future change becomes harder to reason about

So Clean Core is not optional.

But Clean Core is still not the whole architecture.

It tells you what should not happen inside the core.

It does not automatically tell you how the extension landscape should be governed outside the core.

A clean S/4HANA core does not automatically prove that:

• your BTP identity chain is valid
• your tenant model is reconstructible
• your HDI data remains subordinate to S/4 truth
• your AppRouter / Work Zone entry path represents real production conditions
• your destinations preserve the right propagation contract
• your schema evolution can move from version N to N+1 across tenants
• your integration semantics remain stable after an upgrade

Clean Core protects the anchor.

But the extension landscape still needs architecture.

And architecture still needs judgment.

3. The Responsibility Gap After RISE

One of the hardest problems in enterprise SAP landscapes is not technical.

It is jurisdictional.

After RISE, responsibility can appear clearer at the macro level.

But at the extension level, responsibility often becomes more fragmented:

• SAP owns or governs parts of the core operating model
• partners implement extension scenarios
• internal teams own business process requirements
• security teams own identity providers and trust settings
• integration teams own destinations and middleware
• application teams own CAP services
• platform teams own subaccounts, entitlements, and runtime operations
• business teams own process outcomes

Each team may be competent.

Each component may be locally correct.

But the extension succeeds or fails in the relationships between components.

That is the gap.

Who owns the full identity chain?

Who owns tenant reconstructibility?

Who owns the difference between S/4 truth and extension-owned data?

Who owns integration semantics across Work Zone, AppRouter, CAP, destinations, and S/4?

Who proves that onboarding, migration, rollback, and upgrade can happen without manual reconstruction?

If the answer is unclear, the extension architecture is not yet governed.

RISE does not automatically close that gap.

Someone still has to judge the boundaries.

4. Five Decisions RISE Does Not Make for Your BTP Extension

4.1 RISE Does Not Decide Your Identity Chain

Identity on SAP BTP is not a login event.

It is a chain:

IdP / IAS → XSUAA → AppRouter → CAP → destination → S/4HANA

Every hop transforms context.

Every hop can preserve, weaken, overwrite, or lose meaning.

A system can appear correct locally:

• login succeeds
• token validates
• CAP sees a user
• destination connects
• S/4 returns data

But identity correctness is not local.

It is compositional.

The real question is:

Does the same identity meaning survive across the real enterprise path?

Not just in Postman. Not just through a technical user. Not just through a protected test path.

Through the actual Work Zone / AppRouter / CAP / destination / S/4 chain.

RISE does not decide that for you.

4.2 RISE Does Not Decide Your Tenant Boundary

On BTP, tenant context is not a decorative label.

It shapes:

• routing
• role collections
• subscriptions
• service instances
• HDI containers
• onboarding
• lifecycle evolution

Many projects still treat tenancy as if it were only a deployment or data-isolation concern.

That is too small.

The real question is:

Can every tenant evolve through the same architectural timeline without divergence?

A tenant model is not proven because one tenant works.

It is proven when a new tenant can be onboarded into a correct state without manual repair.

It is proven when version N can become version N+1 across tenants deterministically.

It is proven when tenant context remains consistent across identity, routing, data, integration, and lifecycle.

RISE does not decide that for you.

4.3 RISE Does Not Decide Your Data Boundary

Clean Core says the core should remain clean.

But BTP extensions still have to decide what data they own.

This is where many extensions quietly fail.

The common pattern looks harmless:

• replicate S/4 master data for performance
• store business attributes in HDI for convenience
• cache authoritative fields for UI speed
• enrich extension tables with core semantics
• let local data drive business decisions

At first, everything works.

Then time passes.

A tenant is onboarded. A schema changes. An S/4 upgrade shifts semantics. A reconciliation is required. A region rollout begins. A rollback is needed.

Suddenly the extension cannot reconstruct truth.

That is not a database problem.

It is a Data Boundary failure.

The key question is:

Who owns the truth?

S/4 owns business truth. The extension may own extension truth. Derived data may be stored locally, but it must remain rebuildable and non-authoritative.

If replicated data becomes decision-critical truth, shadow truth has formed.

RISE does not automatically prevent that.

Clean Core protects the core from modification.

It does not automatically prevent the extension from creating a second truth outside the core.

That still requires architectural judgment.

4.4 RISE Does Not Decide Your Integration Contract

Connectivity is not integration.

A destination can connect. An API can respond. A token can validate. An event can fire.

But integration is not proven until the semantics are governed.

The real questions are:

• What identity is authoritative at each hop?
• Where is tenant context derived?
• Which entry path is canonical?
• Which destination scope is valid for which call?
• What is allowed to change during upgrade?
• Who owns contract compatibility?
• What evidence proves responsibility when behavior breaks?

If these answers are implicit, the integration is fragile.

It may still work.

But it works because people remember the rules.

That is not architecture.

That is institutional memory pretending to be architecture.

RISE does not write your integration contract.

BTP provides mechanisms.

Your architecture must still define jurisdiction.

4.5 RISE Does Not Decide Your Lifecycle Reconstructibility

This is the hardest boundary.

Most systems are judged too early.

They are judged at go-live:

• Does it deploy?
• Does login work?
• Does the UI open?
• Does the API return data?
• Does the pilot tenant succeed?

But BTP extensions are not truly judged at go-live.

They are judged by lifecycle events:

• tenant onboarding
• schema migration
• S/4 upgrade
• identity hardening
• region rollout
• environment split
• rollback
• deprovisioning
• ownership transfer

A system is not stable because it runs today.

It is stable if it can reach its next correct state without manual reconstruction.

That is reconstructibility.

The minimal tests are simple:

Can a brand-new tenant be onboarded into a correct state without manual repair?

Can version N become version N+1 across all tenants without divergence?

If the answer is no, the extension may still operate.

But architecturally, it is already unsafe.

RISE does not answer those questions.

Architecture judgment does.

5. The Dangerous Assumption: “SAP Is Responsible Now”

In RISE conversations, an implicit assumption sometimes appears:

“SAP is responsible for more of the landscape now, so the architecture risk is lower.”

Sometimes that is true at the operating model level.

But it does not automatically follow at the extension architecture level.

A side-by-side extension still introduces decisions that SAP cannot make for the customer:

• what business truth the extension may store
• what tenant model represents the organization
• what identity propagation semantics are required
• what integration contract is acceptable
• what lifecycle risks the business can tolerate
• what future rollout paths must remain possible

These are not merely platform decisions.

They are architecture decisions.

And in many programs, they are also business decisions disguised as technical configuration.

No vendor, partner, or platform can fully decide them by default.

They must be made explicitly.

And when they are made implicitly, they become future failure modes.

6. Why This Becomes an Architecture Judgment Problem

A delivery problem asks:

Can the team make it work?

An architecture judgment problem asks:

Are we proving the right architecture at all?

After RISE, this distinction becomes even more important.

Because the organization may already feel strategically aligned:

• RISE direction chosen
• Clean Core accepted
• BTP extension pattern selected
• implementation partner engaged
• project governance in motion

At that point, the danger is not lack of direction.

The danger is false architectural confidence.

The project may assume that because the macro direction is correct, the extension design is also correct.

But BTP extension failures rarely begin as obvious contradictions to strategy.

They begin as small boundary erosions:

• a technical user used to simplify propagation
• a destination shared across tenant-specific flows
• a replicated table treated as truth
• a manual onboarding step accepted as normal
• a direct path considered equivalent to the real entry path
• a migration script that works only in one environment
• a role mapping that nobody can reconstruct later

Each decision looks practical.

Each may even be rational locally.

But together, they determine whether the extension can survive time.

This is why architecture judgment matters.

It classifies whether current success is proof — or merely force.

7. RISE Can Make Extension Judgment More Important, Not Less

This may sound counterintuitive.

But the cleaner the core becomes, the more visible the extension architecture becomes.

In a heavily customized legacy landscape, many failures are absorbed into the core itself.

Everything is mixed:

• process logic
• custom tables
• local semantics
• integration shortcuts
• reporting assumptions
• operational exceptions

Once the core becomes cleaner, those responsibilities move outward.

They do not disappear.

They move into:

• BTP extensions
• integration layers
• side-by-side applications
• workflow automation
• event-driven processes
• data products
• AI-assisted services

This is good.

But it also means the extension landscape must carry more architectural responsibility.

The core may become cleaner.

The extensions must become more disciplined.

Otherwise the enterprise simply moves disorder from the core into the edge.

And a dirty edge can eventually become just as dangerous as a dirty core.

8. What a Real Extension Verdict Must Prove

A serious SAP BTP architecture verdict should not merely ask whether the extension follows a reference pattern.

It should ask whether the extension preserves the boundaries required for long-term evolution.

At minimum, it must test:

Identity

Does user and tenant meaning survive the real operating path?

Tenant

Can new tenants be onboarded without manual repair or hidden assumptions?

Data

Is S/4 business truth protected from shadow truth in HDI or extension storage?

Integration

Are semantics governed by explicit contracts, not endpoint success?

Runtime

Are responsibilities correctly assigned across Work Zone, AppRouter, CAP, HDI, CF, Kyma, and integration layers?

Lifecycle

Can the system evolve, migrate, rollback, and reconstruct across tenants and environments?

This is not generic governance.

It is architectural proof.

And without that proof, the system may be directionally aligned but structurally unsafe.

9. The Real Question After RISE

After RISE, the question is not only:

Are we moving to the right SAP operating model?

That question matters.

But it is not enough.

The harder question is:

Can our extension landscape remain structurally correct as the core, tenants, identities, data contracts, integrations, and lifecycle conditions evolve?

That is the question most programs do not ask early enough.

They ask whether the extension can be delivered.

They ask whether the components are configured.

They ask whether the project is on track.

They ask whether the demo works.

But they do not ask whether the architecture can survive its next correct state.

That is the missing question.

And it is the question that separates delivery confidence from architectural confidence.

10. The Boundary Model View

From the Boundary Model perspective, RISE does not remove boundaries.

It clarifies where some of them should be protected.

But the extension still lives across boundaries:

• Identity Boundary
• Tenant Boundary
• Data Boundary
• Integration Boundary
• Runtime Boundary
• Lifecycle Boundary

The failure mode is not that RISE is insufficient.

The failure mode is believing that RISE eliminates the need to own these boundaries.

It does not.

Every extension still has to answer:

• Where does identity change meaning?
• Where does tenant context originate?
• Where does business truth live?
• Where does integration become a contract?
• Where does runtime responsibility begin and end?
• Where does lifecycle remain deterministic?

If these questions are not answered explicitly, they will be answered accidentally.

And accidental architecture is rarely safe.

Closing — RISE Gives Direction. Judgment Gives Certainty.

RISE matters.

Clean Core matters.

BTP matters.

But they do not replace architectural judgment.

They create the conditions where judgment becomes more valuable.

Because once the enterprise commits to a cleaner core and a BTP-based extension strategy, the central risk moves from:

“Are we modernizing?”

to:

“Are we extending correctly?”

That second question cannot be answered by strategy language alone.

It must be answered through boundary evidence.

RISE may define how the core is operated. Clean Core may protect what the core should remain. BTP may provide the extension foundation.

But none of them decides whether your extension architecture is structurally safe to evolve.

That verdict still has to be made.

And in long-lived SAP landscapes, that verdict may be the difference between a system that merely goes live — and a system that remains governable for years.