By Caleb Billingsley, AI Testing and Performance Expert, Foulk Consulting
For decades, enterprise ERP landscapes were defined by pervasive customization. When business logic required unique billing rules, bespoke pricing algorithms, or complex supply chain scheduling, developers wrote custom ABAP directly inside the SAP core. While this model accommodated complex business requirements, it accumulated immense technical debt: monolithic ERP systems locked in place by custom code, Z-tables, and user exits that turned routine upgrades into high-risk, multi-million-dollar migration projects.
To break this cycle, SAP introduced the Clean Core strategy. However, widespread confusion surrounds what Clean Core actually mandates. Clean Core does not mean deporting every piece of custom code off the ERP to side-by-side platforms like SAP Business Technology Platform (BTP) or external hyperscalers. Rather, SAP defines a dual-path extensibility model:
- On-Stack Developer Extensibility: Custom logic implemented directly within the S/4HANA stack using ABAP Cloud and the ABAP RESTful Application Programming Model (RAP), restricted exclusively to released SAP APIs and extension points.
- Side-by-Side Extensibility: Applications, integrations, and microservices hosted externally on SAP BTP or hyperscalers (AWS, Azure, GCP) to deliver complete lifecycle isolation from the core ERP.
Herein lies The Performance Paradox. The paradox does not stem from Clean Core governance itself, but from an architectural misplacement: treating side-by-side extensibility as a blanket requirement for all custom business logic. When teams extract chatty, data-intensive, or transactional routines into external microservices, they replace in-process execution with distributed network hops. If architects do not design and validate specifically for distributed network latency, a “clean” core can run significantly slower than the legacy system it replaced.
The Latency Tax: What Mechanically Changes?
A common misconception among modernization teams is that classic on-premise ERP code ran in zero-latency shared memory, whereas cloud architectures run over the wire. In reality, traditional custom ABAP never operated with zero latency; it executed within dialog work processes and communicated with the SAP HANA or legacy relational database via SQLDBC, regularly incurring SQL compilation, lock contention, and I/O execution times measured in tens to hundreds of milliseconds.
Moving logic to a side-by-side platform does not eliminate that database or execution overhead. Instead, it stacks distributed network, security, and protocol serialization overhead directly on top of it. In a side-by-side architecture, the total end-to-end transaction latency is expressed as:
T_total = T_ui + Σ(T_net + T_tls + T_auth + T_scc + T_gw + T_abap + T_db) + T_queue
To understand where elapsed time accumulates, performance engineers must distinguish between the initial cold-start connection cost and steady-state transaction hops:
- Cold-Start Overhead: The initial request must resolve DNS, complete the TLS handshake, authenticate through XSUAA or identity providers to obtain an OAuth2 bearer token, and establish an encrypted tunnel via the SAP Cloud Connector (SCC).
- Steady-State Latency: While HTTP keep-alive, TLS session resumption, and token caching amortize handshake costs, every subsequent request still incurs round-trip network transit (T_net), JSON serialization/deserialization, Destination Service routing, SAP Gateway dispatching (T_gw), and work-process scheduling.
The acute performance penalty emerges when development teams fall into the Chatty API Anti-Pattern, attempting a 1:1 functional conversion of legacy ABAP subroutines into discrete remote API calls. A legacy process that executed 30 internal function modules within a single database transaction now generates 30 sequential HTTPS calls across network and cloud boundaries.
| Architecture Model | Execution Path | Per-Step Latency Profile | Clean Core Alignment |
| Classic Monolith (ECC / S/4) | In-process ABAP execution; local SQLDBC calls to database. | 10ms – 150ms total dialog step (dominated by SQL and locks). | Violated (direct modifications, custom Z-tables). |
| Misplaced Side-by-Side (Anti-Pattern) | External microservice executing 30–50 fine-grained OData calls via Cloud Connector. | 20ms – 50ms per network hop + serialization + core processing per call. | Technically isolated, but operationally flawed. |
| Architected Clean Core (Dual-Path) | On-stack ABAP Cloud (RAP) for core transactions; coarse OData façade for BTP apps. | Single coarse network request (40ms RTT) + efficient in-stack execution. | Fully Compliant (Level A upgradable). |
Deconstructing the Latency Math: The 2-Second Floor and Little’s Law
To evaluate the real-world impact of distributed architecture, enterprise architects must ground their analysis in rigorous queuing theory and network arithmetic rather than rough approximations.
Consider an order-to-cash workflow where an external BTP portal orchestrates 50 sequential remote read and validate calls against S/4HANA. Assuming an optimized, co-located steady-state round-trip time (RTT) of 40ms per call across the API gateway, Cloud Connector, and back, the baseline calculation is clear:
50 hops × 40 ms = 2.0 seconds of network transit time alone
This 2.0-second figure is a physical floor, it represents the elapsed time before the S/4HANA core performs a single database lookup, evaluates a business rule, or parses a payload. However, during peak enterprise usage, response times frequently expand from this 2.0-second baseline into an 8-second bottleneck. Why?
Active named users do not act as direct multipliers on hop latency. Instead, load creates queuing delay governed by Little’s Law (L = λW). As concurrent user arrival rates (λ) increase, queuing time (T_queue) expands nonlinearly whenever shared infrastructure resources reach saturation:
- Cloud Connector Tunnel Saturation: Sequential API requests contend for multiplexed worker threads and socket pools within the SAP Cloud Connector instance.
- ICM and Work-Process Queues: On the S/4HANA core, the Internet Communication Manager (ICM) and dialog work processes (DIA) become backlogged as incoming HTTPS requests monopolize work slots.
- Serialization and Memory Pressure: Transforming 50 distinct ABAP internal tables into JSON payloads consumes central CPU cycles on both the BTP runtime and the SAP Gateway.
In one recent RISE migration cutover evaluated by Foulk Consulting, an enterprise decomposed a standard materials availability check into 35 fine-grained OData calls executed by an external portal. In isolated unit tests with a single user, the page refreshed in 1.4 seconds. But during mock cutover testing with 400 concurrent users, the 95th-percentile (p95) transaction time spiked past 7.8 seconds. The root cause was not database latency on HANA; it was thread pool exhaustion across the Cloud Connector and ICM worker queue wait times.
The Visibility Gap: Clean Core in RISE with SAP Environments
Managing distributed latency is particularly complex in RISE with SAP managed cloud environments, specifically within Private Cloud Edition (PCE). In managed cloud ERP contracts, enterprise IT teams operate across a strict administrative demarcation line: they no longer possess root-level hypervisor access, deep OS-level performance monitoring, or granular virtual network interface statistics within the SAP-managed VPC.
When an end-user experiences severe degradation in a Clean Core setup running on RISE PCE, diagnosing the root cause becomes an immediate operational challenge:
- Is the bottleneck within the custom Node.js or Java runtime on SAP BTP?
- Is it transit latency or packet drop across the Direct Connect, Azure ExpressRoute, or AWS Transit Gateway network hub?
- Is it connection queuing inside the on-premise or cloud-hosted SAP Cloud Connector?
- Is an unindexed OData query tying up dialog work processes on the S/4HANA core?
- Or is the SAP Gateway throttling incoming connections under peak concurrency?
Without a cohesive performance engineering framework, troubleshooting quickly dissolves into multi-vendor finger-pointing among the internal application team, the hyperscaler support organization, and SAP Enterprise Cloud Services (ECS).
Architectural Remedies: Designing for Speed and Clean Core Governance
Achieving architectural cleanliness does not require sacrificing responsiveness. By applying sound distributed systems design and adhering to SAP’s extensibility guidelines, engineering teams can maintain both upgrade agility and high performance:
Remedy 0: Keep Transactional and High-Round-Trip Logic On-Stack (ABAP Cloud / RAP)
The most critical architectural decision is proper placement. If a custom business process requires intensive SQL joins, processes high volumes of operational records, or must participate in a single SAP Logical Unit of Work (LUW) with standard transactional data, it belongs on-stack. Implementing this logic using ABAP Cloud and RAP on released SAP APIs satisfies Clean Core compliance completely while avoiding external network latency altogether. Side-by-side placement should be reserved for decoupled applications, specialized partner integrations, or independent lifecycle workflows.
Remedy 1: Regional Placement, SAP BTP Co-Location, and Private Link
Physical topology dictates network baseline latency. If your SAP S/4HANA Cloud PCE instance is hosted in AWS us-east-1 (N. Virginia) and your SAP BTP subaccount is deployed in AWS us-west-2 (Oregon), every API round trip incurs an immutable 60ms to 70ms wide-area network latency penalty. Ensure your SAP BTP subaccount region (e.g., AWS us10) matches the physical hyperscaler data center hosting your ERP core. Furthermore, leverage SAP Private Link or dedicated cloud interconnects (AWS Direct Connect, Azure ExpressRoute) rather than routing production traffic over the public internet.
Remedy 2: Event-Driven Architecture (EDA) for Downstream Consumers
Eliminate synchronous polling by external microservices. For enterprise-scale architectures, deploy SAP Integration Suite, advanced event mesh (AEM) or cloud-native event streaming (e.g., Apache Kafka) to distribute state changes asynchronously. However, architects must account for the synchronous user experience: when a user clicks “Submit Order,” the initial transactional write and validation require a synchronous response (ACK). Asynchronous event publishing should handle downstream read-model projections, logistics notifications, and analytics pipelines without blocking the primary user interface.
Remedy 3: Coarse-Grained OData v4 and $batch Projections
When remote connectivity is necessary, eliminate chatty, fine-grained calls. Build coarse-grained OData v4 services on the core using RAP that encapsulate composite operations into a single network envelope. Where multiple operations must execute, combine them using OData $batch requests. Always apply strict $select and $expand query parameters to return only the attributes required by the client UI, minimizing JSON serialization and wire payload overhead.
Remedy 4: Read-Side In-Memory Caching for Stable Master Data
Do not force client applications to query the S/4HANA core for stable reference data. Cache slowly changing master data, such as product catalog definitions, plant master records, units of measure (UoM), customer hierarchy structures, and business partner display attributes, in an in-memory cache tier (such as Redis on SAP BTP). Caution: Never attempt to cache dynamic, date-effective, or jurisdiction-heavy calculations such as tax determination (e.g., Vertex or Avalara integrations); stale tax rules represent a severe business and legal compliance defect.
The Foulk Performance Playbook: Validating a Clean Core Architecture
Validating decoupled ERP architectures requires shifting away from legacy performance testing that merely hits isolated endpoints in a lab. Real-world validation must replicate the complex concurrency, security, and networking dynamics of hybrid cloud environments:
- Test Composite Business Journeys: Validate complete end-to-end user transactions spanning from the external client application or Fiori UI, across SAP BTP, through the SAP Cloud Connector, into the S/4HANA core, and out to downstream event queues. Measure p95 and p99 response times at the composite journey level rather than benchmarking isolated API endpoints.
- Inject Network Jitter and Cross-Cloud Friction: In staging environments, utilize chaos engineering techniques to inject realistic network conditions: 30ms to 100ms of latency jitter, intermittent packet drop, and DNS resolution latency between BTP and the ERP core. Verify that connection pooling handles transient degradation gracefully without thread starvation or cascading failure.
- Correlate Telemetry Across the Boundary: Bridge the RISE visibility boundary with a correlated two-layer observability model. Propagate W3C trace context headers through SAP BTP and API gateways into the SAP Gateway. From there, correlate with native SAP performance diagnostics, including SAP Cloud ALM, transaction traces (STAD/SAT), SQL performance monitors (SQLM/ST05), and SAP HANA expensive statement logs. Foulk Consulting pairs enterprise APM solutions like Dynatrace (with its dedicated SAP monitoring extensions) to maintain continuous transaction lineage from front-end click to back-end database execution.
- Stress-Test Authentication and Token Concurrency: Security handshakes under load are frequent silent bottlenecks. Stress-test OAuth2/XSUAA token negotiation, principal propagation workflows, and Destination Service connection caches under peak concurrent user arrival rates to ensure authentication layers do not cause connection stampedes or thread pool exhaustion.
Balancing Architectural Purity with Real-World Performance
SAP’s Clean Core strategy provides enterprise organizations with an indispensable roadmap to break free from upgrade paralysis and achieve continuous agility. However, architectural purity should never be pursued at the expense of system responsiveness and end-user productivity.
By properly distinguishing between on-stack ABAP Cloud extensibility and side-by-side BTP deployment, eliminating chatty remote API antipatterns, co-locating cloud regions, and validating composite user journeys under real-world concurrency, engineering leaders can resolve the Clean Core paradox, delivering an ERP architecture that is both effortlessly upgradable and exceptionally responsive.
Need to validate your SAP S/4HANA migration, RISE cloud architecture, or BTP extension performance? Connect with the performance engineering team at Foulk Consulting to stress-test your architecture before deployment.
