Deciding What Belongs on BTP: Extension Options and Trade-offs

Explanation

Once an organization accepts that BTP strategy requires deliberate decisions rather than defaults, the next step is a repeatable framework consultants can apply project after project. At intermediate level, this means understanding the concrete options available and the trade-offs between them, not just the philosophy. The first option is in-app extensibility within S/4HANA itself. In S/4HANA Cloud Public Edition, this is tightly scoped to key-user tools and released extension points (custom fields, custom logic via released BAdIs, custom CDS views built on released objects). In S/4HANA Private Cloud Edition and on-premise, in-app extensibility can also include developer extensibility using ABAP in a more traditional sense, though SAP still recommends favoring released APIs and extension points to protect upgradability. The trade-off: in-app extensions are simpler operationally (one system, one lifecycle) but are constrained by what SAP has released as extensible, and overuse can still create upgrade friction if governance is weak. The second option is side-by-side extension on BTP, typically using the ABAP Environment (Steampunk-style), Cloud Foundry, or Kyma runtime, communicating with S/4HANA through released OData/REST APIs or event-based integration. This decouples the extension's release cycle from the core system, allows use of modern languages and frameworks, and isolates custom code so it cannot directly destabilize the ERP core. The trade-off: it introduces a second platform to secure, monitor, and pay for; network latency and integration reliability become real NFR concerns; and teams need skills beyond classic ABAP (e.g., Java/Node.js, Kubernetes concepts for Kyma, API design). The third option, often overlooked, is challenging the requirement itself: does S/4HANA already provide this capability in standard, perhaps configured differently, or is it a process redesign opportunity rather than a coding problem? Architects should always test this option first, because it has zero long-term maintenance cost compared to either extensibility path. Decision criteria that should feed into the choice include: coupling and reuse (does the logic need to be reused by multiple systems beyond S/4HANA, favoring side-by-side), release cadence mismatch (does the extension need to change more frequently than SAP's core release cycle allows, favoring side-by-side), data volume and latency sensitivity (high-frequency, low-latency logic may be harder to justify remotely on BTP), team skills and operating model (does the organization have capacity to run and secure a second platform), and regulatory/data residency constraints (some industries restrict where certain data can be processed, which can rule out specific BTP regions or services). A common intermediate-level mistake is evaluating these trade-offs purely on technical elegance while ignoring total cost of ownership: BTP side-by-side extensions require their own change management, monitoring, and security patching cadence, distinct from the ERP's. The decision framework should be captured as a lightweight architecture decision record (ADR) per extension, not a one-time whitepaper, because requirements and SAP's extensibility catalog both evolve.

Code example

# Illustrative decision checklist (not a real SAP tool; a project artifact template)# Extension Candidate: Custom Rebate Calculation Engine criteria = {    "standard_functionality_available": False,    "can_use_released_extension_point": False,   # e.g., no suitable BAdI/CDS extension    "needs_independent_release_cycle": True,      # business changes rules monthly    "reused_by_non_SAP_systems": True,            # e-commerce also needs rebate logic    "latency_sensitive_realtime": False,    "team_has_cloud_dev_skills": True,    "data_residency_constraint": None} def recommend_placement(criteria):    if criteria["standard_functionality_available"]:        return "Use standard SAP functionality"    if not criteria["can_use_released_extension_point"] and criteria["needs_independent_release_cycle"]:        return "Side-by-side extension on BTP (e.g., ABAP Environment or Cloud Foundry)"    if criteria["can_use_released_extension_point"]:        return "In-app extensibility (key-user or developer extensibility)"    return "Escalate to architecture board for manual review" print(recommend_placement(criteria))# Expected output guidance: Side-by-side extension on BTP# NOTE: this is a simplified illustrative model for teaching decision logic,# not an official SAP tool or guaranteed outcome.

Real project scenario

A logistics company needed a rebate engine shared between S/4HANA and a non-SAP e-commerce platform, with business rules changing monthly based on carrier negotiations. The architecture team initially considered a custom BAdI implementation inside S/4HANA, but rejected it because the e-commerce platform had no access to ERP-internal extension points and the monthly rule changes would have required repeated core system transports. They built the rebate engine as a side-by-side application on BTP Cloud Foundry, exposing an API consumed by both S/4HANA (via a released API) and the e-commerce platform, with its own independent deployment pipeline.

Common mistakes

• Choosing side-by-side extension for convenience when a released in-app extension point would have worked and been simpler to operate. • Ignoring reuse requirements and building the same logic twice, once in-app and once on BTP, for different consuming systems. • Underestimating the operational cost of running and securing a second platform when justifying a side-by-side decision. • Not revisiting earlier decisions when SAP releases new extension points that could replace a side-by-side workaround. • Failing to document decision rationale, making it hard for future architects to know why an extension lives where it does.

Best practices

• Always test whether standard functionality or configuration solves the requirement before considering any extensibility path. • Prefer in-app extensibility using released extension points when reuse outside S/4HANA is not required. • Reserve side-by-side BTP extensions for cases with independent release cycles, cross-system reuse, or capabilities not available in-app. • Capture each significant extension decision as a lightweight ADR including criteria considered and rejected alternatives. • Periodically re-evaluate side-by-side extensions against newly released in-app extensibility options.

Interview angle

A frequent architect interview question is to present a vague requirement and ask the candidate to walk through where they would place the logic. Strong candidates ask clarifying questions about reuse, release cadence, latency, and team skills before answering, and explicitly consider 'no-code' standard functionality first rather than jumping to BTP.