Every SAP landscape eventually reaches the same inflection point. Standard SAP covers the core processes well. But the business has requirements that standard does not meet — a unique approval workflow, a custom user interface for a specific team, a process extension that reflects how this company operates rather than how SAP’s generic best practice assumes it operates.
At this inflection point, a decision gets made. That decision — how to extend SAP — is one of the most consequential architecture choices in the SAP program. Made well, it produces a landscape that evolves cleanly, upgrades without pain, and builds institutional capability for future innovation. Made poorly, it produces technical debt that compounds silently until it announces itself as an upgrade crisis or a performance problem that requires a remediation program to resolve.
The principle that governs the right decision is BTP-first: when standard SAP configuration is not sufficient, extend through SAP BTP — not through modifications to the SAP core. This blog explains what that principle looks like in practice, across five common extension scenarios, through the lens of what right and wrong actually look like side by side.
The three extension layers — in order of preference:
1. Standard SAP configuration — always attempt this first. No development, fully upgrade-safe.
2. SAP-delivered extensibility (Key User Extensions, BAdIs) — SAP’s own extension points. Upgrade-safe by design.
3. SAP BTP side-by-side extensions — custom development outside the core. Upgrade-safe when built correctly.
What is never on this list: modifications to SAP standard objects. Not because they are always catastrophic — but because their cost compounds with every upgrade, and BTP eliminates the need for them in the vast majority of cases.
Scenario 1: Custom Approval Workflow
One of the most common extension requirements in SAP programs. The business needs an approval process that differs from SAP’s standard workflow — additional approvers, conditional routing based on business rules, escalation paths, and mobile approval capability.
✗ Building the workflow inside the SAP core
The workflow logic is implemented by modifying SAP’s standard workflow objects or writing custom ABAP code inside the core. It works. It is tested. It goes live. And it stays exactly as built — because every change requires a developer, every SAP upgrade requires re-validation of the custom logic, and the workflow cannot be changed by the business without IT involvement.
Consequence: The workflow becomes a maintenance burden. Business process changes require development effort. Upgrades require regression testing of custom code. The workflow is exactly as flexible as the day it was built — which is not very flexible at all.
✓ Building the workflow on SAP BTP Workflow Management
The workflow is built as a BTP application using SAP’s Workflow Management service. It calls S/4HANA standard APIs to read and update business objects. The workflow logic lives outside the SAP core, is versioned independently, and can be modified by a suitably skilled business analyst without touching the ERP. Mobile approval is available through SAP’s standard mobile inbox.
Outcome: Workflow changes are made in BTP without ERP involvement. SAP upgrades do not affect the workflow. Business teams can iterate on approval logic without opening a development ticket. The extension is upgrade-safe and operationally agile.
Scenario 2: Custom User Interface for a Specific Team
A warehouse team, a field service technician, or a finance analyst needs a simplified, role-specific interface that SAP’s standard Fiori applications do not provide. The standard app shows too much, requires too many steps, or does not match the physical workflow of the team using it.
✗ Modifying the standard SAP Fiori application
The standard Fiori app is modified — fields are hidden, steps are rearranged, and custom logic is added to the app’s controller. The modified app is tested and deployed. It works well for the specific team. It also diverges from SAP’s delivered application, which means every SAP update to that application needs to be merged with the custom modifications.
Consequence: Each SAP update to the standard Fiori app creates a merge conflict with the customizations. Over time, the custom app falls behind SAP’s delivered version — missing security patches, performance improvements, and new features. Maintaining the modifications becomes a recurring cost.
✓ Building a custom Fiori application on SAP BTP
A new Fiori application is built on SAP BTP using SAP’s UI5 framework, calling S/4HANA standard OData APIs for all data access and business logic. The UI is custom; the business logic is standard. The custom app lives on BTP, completely independent of SAP’s delivered applications. SAP updates to the underlying APIs are handled through standard versioning.
Outcome: The custom UI evolves independently of SAP upgrades. The standard APIs it calls remain stable and supported. The team gets exactly the interface they need. SAP’s standard application updates continue delivering security and performance improvements to the underlying platform without affecting the custom UI.
Scenario 3: Process Extension with External Data
A business process in SAP needs to incorporate data from an external system — a credit scoring service, a logistics provider API, a regulatory compliance database, and a market data feed. The external data needs to be available within the SAP transaction or workflow at the moment of decision.
✗ Calling the external service directly from ABAP inside the core
A custom ABAP function module is written to call the external API. It is embedded in a user exit or BAdI implementation that fires during the relevant SAP transaction. The external data is retrieved synchronously during transaction processing. If the external service is slow or unavailable, the SAP transaction is delayed or fails.
Consequence: The SAP core has a direct dependency on an external system. Performance issues in the external service cause performance issues in SAP transactions. The external API call needs to be maintained as the external service evolves. The dependency is invisible to SAP’s standard monitoring and error handling.
✓ Building the integration on SAP BTP Integration Suite
The external service call is implemented as an integration flow on SAP BTP Integration Suite. S/4HANA publishes an event or makes an API call to BTP when external data is needed. BTP handles the external service call, manages error handling and retry logic, and returns the result to S/4HANA through a standard API. The core has no direct dependency on the external system.
Outcome: External service dependencies are managed in BTP, not in the SAP core. Integration Suite’s monitoring and error handling capabilities apply. The external API call can be updated, retried, or rerouted without touching SAP. Performance of the external service does not directly affect SAP transaction performance.
Scenario 4: Custom Reporting and Analytics
A business team needs a report or analytical view that SAP’s standard reporting tools do not provide — combining data from multiple SAP modules, incorporating calculated fields, and presenting in a format specific to their operational workflow.
✗ Building a custom ABAP report with direct database access
A developer writes a custom ABAP report that queries SAP database tables directly, performs calculations in ABAP code, and outputs results in a custom ALV grid or download. The report works and is used daily. It also accesses database tables whose structure is not guaranteed to remain stable across SAP releases.
Consequence: SAP releases that change the structure of accessed database tables break the report. The report requires developer involvement for every change — new fields, different calculations, different output format. Performance issues in the report affect the SAP system because it runs on the same database.
✓ Building the report on SAP Analytics Cloud connected via live data connection
The report is built in SAP Analytics Cloud, connected to S/4HANA through a live data connection that uses SAP’s published CDS views — stable, supported, upgrade-safe data access layers that SAP maintains and evolves. The report logic lives in SAC, not in the SAP core. Business users with appropriate training can modify the report without developer involvement.
Outcome: The report is independent of SAP’s internal database structure. SAP upgrades that change internal tables do not affect the report as long as the CDS view layer is stable. Business users can modify, extend, and share the report without IT involvement. The report scales independently of SAP system performance.
Scenario 5: Business Rule Management
The business has rules that change frequently — pricing rules, credit limit thresholds, approval authority limits, compliance checklists. These rules are currently hardcoded in SAP configuration or custom ABAP, requiring a developer and a transport to change.
✗ Hardcoding business rules in SAP configuration or custom ABAP
Business rules are implemented as SAP configuration entries or ABAP condition logic. Changing a rule requires raising a change request, having a developer make the change, testing it in development, transporting through quality, and deploying to production. The cycle takes days to weeks for what is fundamentally a business decision.
Consequence: Business agility is constrained by IT change management cycles. Rules that should change monthly take weeks to implement. The SAP change management process — designed for system changes — is applied to business decisions. The business works around the system rather than through it.
✓ Externalizing business rules to SAP BTP Business Rules service
Business rules are implemented using SAP BTP’s Business Rules service — a managed rules engine where rules are defined as structured decision tables that authorized business users can modify directly through a web interface. S/4HANA calls the rules service via API when rule evaluation is needed. Rule changes do not require SAP transports.
Outcome: Business users can change pricing thresholds, approval limits, and compliance rules directly without IT involvement. Rule changes are versioned and auditable in BTP. The SAP core is not involved in rule changes. Business agility is decoupled from IT change management cycles.
The Pattern That Runs Through Every Scenario
Reading across these five scenarios, the architectural principle is consistent. BTP-first architecture does not mean building everything on BTP. It means keeping the SAP core stable and standard — and placing all custom logic, all custom interfaces, all external dependencies, and all frequently-changing business rules in the layer that is designed to accommodate them.
The SAP core manages business objects, transactions, and process logic that SAP owns and evolves. BTP manages the extensions, integrations, and custom capabilities that the business owns and evolves. The boundary between them is maintained through SAP’s published APIs — stable contracts that allow both sides to evolve independently.
When that boundary is maintained, SAP upgrades are routine. When it is violated — when custom logic is embedded in the core, when external systems are called directly from ABAP, when standard applications are modified — upgrades become projects in themselves.
The test for every extension decision:
“If SAP releases a major update tomorrow, will this extension require developer involvement to validate?”
If the answer is yes, the extension is in the wrong place. BTP-first architecture means the answer is almost always no.
What This Requires of Your SAP Team
BTP-first architecture is a discipline, not a tool. The tool — SAP BTP — makes it possible. The discipline makes it real. And that discipline requires capabilities that not all SAP teams currently have.
BTP development skills. Building on BTP requires different skills from ABAP development — CAP (Cloud Application Programming model), SAP UI5, OData services, Cloud Foundry deployment. Teams that only have ABAP developers will default to core modifications because that is what they know how to build. Investing in BTP development capability is a prerequisite for BTP-first delivery.
API-first thinking. BTP-first architecture depends on SAP’s published standard APIs. Developers need to understand how to use OData services, CDS views, and BTP’s API access patterns — and need to resist the temptation to bypass them for direct database access when it feels faster.
Architecture governance. Every extension decision needs to be reviewed against the BTP-first principle before development begins. This requires a governance process — not bureaucratic approval chains, but a lightweight architectural review that ensures extension decisions are deliberate rather than reflexive.
The Bottom Line
BTP-first architecture is not a philosophy — it is a practical delivery standard that determines whether your SAP landscape gets easier or harder to manage over time. Every extension built the wrong way is a future upgrade cost. Every extension built the right way is an upgrade that happens without incident.
The five scenarios in this blog are representative, not exhaustive. The principle applies across every category of SAP extension. The question to ask before every extension project is not ‘can we build this in ABAP?’ — the answer to that is almost always yes. The question is ‘should we?’ — and the answer, with BTP available as the right extension layer, is almost always no.
ASAR Digital’s BTP delivery standard:
Every extension we build starts with the question: Does this belong in the SAP core, in SAP-delivered extensibility, or on BTP? We default to BTP for everything that is not addressable through standard configuration or SAP’s own extension points. It is the only approach that keeps the core clean and the upgrade path clear.
Building an SAP extension and want to make sure it’s done the right way?
ASAR Digital reviews extension architectures before development begins — to make sure the approach is upgrade-safe, scalable, and built on the right layer. Talk to our BTP team before your next extension project gets scoped.