Side-by-Side Extensibility: Deciding What Leaves the Platform, and Building It

Every SAP Commerce estate accumulates requirements that do not belong in the core: a warehouse exception dashboard, a trade-fair lead capture app, a partner onboarding form, a merchandising tool someone sketched in a workshop. The reflex of a platform team is to build them as extensions inside the platform, because that is where the data and the deployment pipeline live. The reflex is frequently wrong, and the cost shows up two years later as a monolith whose release train carries twenty passengers nobody remembers boarding. Side-by-side extensibility is the discipline of building at the edge instead, and this guide covers the decision, the seams, and the delivery options, including the low-code path the old CX Works Mendix series demonstrated.

The Decision: Four Questions#

In-platform extension (a new extension in your codebase, deployed with the platform) versus side-by-side (a separate application on BTP, Kyma, or your own infrastructure, integrating through APIs and events). Ask, in order:

1. Does it change commerce behavior in the request path? Pricing logic, cart calculation hooks, checkout steps, interceptors: in-platform, no debate. The platform's extension points exist precisely for behavior that must execute inside the transaction.
2. Does it have its own lifecycle? A tool that will iterate weekly while the platform releases monthly wants its own deployment cadence. Coupling a fast-moving app to the platform release train taxes both.
3. Does it have its own users or load profile? Internal tools with a dozen users do not belong on storefront infrastructure; event-burst workloads (the high-traffic guide's territory) do not belong where they can steal checkout capacity. Separation of fate is an architecture feature.
4. Could someone other than the platform team own it? If the natural owner is a business-adjacent team, side-by-side (possibly low-code) turns a platform backlog item into something that ships without you.

The pattern in mature estates: the platform codebase gets thinner over time as everything that fails questions two through four migrates out, and what remains is genuinely core commerce behavior. That is the accelerator-era monolith unwinding, and it is the same current that carried storefronts out of the platform (the headless guide's story, one layer down).

The Seams That Make It Safe#

A side-by-side app is only as good as its integration seams. Three, by interaction style:

• OCC REST for anything acting in a customer or session context: carts, orders, account operations. The app is just another head; the API-first rule from the headless guide means these endpoints already exist or should.
• Integration Objects (OData) for system-context data access: master data reads, bulk queries, back-office style writes with the platform's validation. This was the seam the Mendix series used (its OData connector consuming SAP APIs), and it generalizes: any external app, low-code or hand-built, speaks OData to your modeled Integration Objects rather than owning SQL access it must never have. The OData deep-dive guide covers modeling them; the governance rule here is that side-by-side apps get their own Integration Objects, scoped to what they need, instead of piggybacking on some other integration's wide-open object.
• Events for reaction: the app consumes order.created or your custom events (event-driven extensions guide) instead of polling. Polling external apps are the number one source of mystery OCC load; event subscriptions cost nothing at rest.

Cross-cutting: every app gets its own OAuth client (client-credentials for system context, authorization-code for user context) so access is revocable and observable per app; secrets live in the consuming platform's secret store; and rate expectations are written down, because the commerce side's capacity plan (clustering guide) needs to know what the edge can send it.

Delivery Options: Code, Functions, Low-Code#

Functions and microservices on Kyma/BTP are the default for event-driven glue and focused services: small, cheap to run, native to the seams above, with the local development loop from the Kyma guide keeping iteration fast.

Full custom apps (your stack, your infra, same seams) earn their place when the tool is a product: real UI complexity, real roadmap, dedicated team.

Low-code is the historically underrated third option, and the CX Works Mendix series remains a clean demonstration of the shape even as the branding has shifted (SAP's own low-code offering has consolidated around SAP Build; Mendix continues as its own platform). The trade-fair app from that series is the canonical use case dissected:

• An event team needed lead capture on tablets, offline-tolerant, feeding captured contacts and interests into the SAP backend, with a Fiori look and launchpad integration.
• Built low-code: visual domain model mirroring just the entities the app touches, microflows (visual logic) for capture-validate-sync, an OData connector doing the actual integration, deployed to BTP in days rather than sprints.
• The platform team's contribution was not the app; it was the seam: a well-scoped OData surface and an OAuth client. That division of labor is the entire value proposition.

Low-code governance, learned the hard way across estates: treat low-code apps as real software with an inventory (owner, data touched, client credentials, lifecycle), keep them on the same seams as everything else (no database credentials, ever), review the domain model against the Integration Object rather than letting the app invent its own truth, and set an explicit graduation rule: when a low-code app accumulates enough logic that its microflows read like a program, it is re-platformed to code by the four questions above, not patched forever.

Reference Architecture, End to End#

The composite picture for a typical estate:

Commerce Platform (core behavior only)
  |-- OCC ------------------ customer-context heads and apps
  |-- Integration Objects -- system-context apps (low-code tools, dashboards, partners)
  |-- Events (Kyma) -------- reactive functions and workflows
        |-- function: order.created -> ERP notification
        |-- function: review.submitted -> moderation queue
        |-- app: warehouse exception dashboard (OData reads, event-driven refresh)
        |-- app: trade-fair capture (low-code, OData writes via scoped IO)

Each edge component: own lifecycle, own OAuth client, own observability (the integration monitoring guide's freshness and error alerting applies to every arrow), and an entry in the integration inventory. The platform team owns the seams and their contracts; edge teams own their apps; the release trains never couple.

Checklist#

• The four-question decision recorded per extension request; "it was easiest in the monolith" is not an architecture
• OCC / Integration Objects / events chosen per interaction style, not per team habit
• One OAuth client per app; scoped Integration Objects per app; zero shared credentials
• Low-code apps inventoried and on the same seams, with a written graduation rule
• Edge app load expectations documented and visible to capacity planning
• Platform codebase reviewed yearly for extensions that should migrate out

The strategic promise of side-by-side is not any single app; it is the standing capability to say yes to the next business idea without touching the core. Estates that build the seams once find that the twentieth edge app costs a week; estates that kept everything in-platform find that the twentieth extension costs a regression cycle. The gap between those two numbers is most of what "extensibility" means.