Defining Performance NFRs and Sizing Baselines

Explanation

Performance architecture starts long before any technical design decision: it starts with a precise, testable definition of what 'good performance' means for a given business process. Without this, architects end up reacting to complaints instead of designing for outcomes. A performance NFR should state the transaction or process, the expected load (concurrent users, documents per hour, peak vs average), the target response time or throughput, and the conditions under which it must hold (e.g. month-end close, peak sales season). Examples: 'Sales order creation via WebUI must complete in under 2 seconds for 95th percentile under 200 concurrent users' or 'Nightly billing run must process 500,000 documents within a 4-hour batch window.' These statements are testable and become the basis for sizing, load testing, and go-live acceptance.\n\nSizing approaches differ by deployment model. For ECC and S/4HANA on-premise or private cloud, sizing traditionally starts from a throughput-based estimate (transaction volumes, user counts, data growth) that is translated into CPU, memory, and storage requirements, often validated using SAP-provided sizing guidance and reports specific to the product version, then confirmed with a hardware or infrastructure partner. For S/4HANA, in-memory column-store behavior changes the memory-to-data ratio compared to classic ECC on anyDB, so old ECC-era sizing rules of thumb should not be reused without revalidation. For S/4HANA Public Cloud, the customer does not size infrastructure directly; instead, the architect focuses on process design, custom extension footprint, and integration volume, since compute sizing is largely provider-managed within contracted service tiers. For BTP services (Integration Suite, CAP-based apps, Event Mesh), sizing is expressed in service-specific units such as message throughput, API call volume, or database service size, and capacity planning is closer to cloud consumption planning than classical hardware sizing.\n\nMeasurement discipline is as important as the target itself. Established monitoring transactions such as ST03N (workload analysis) and ST04 (database performance) remain valid tools in on-premise and private cloud ABAP stacks to capture actual response time distributions, not just averages, since averages hide tail latency that frustrates users during peak periods. SAP EarlyWatch Alert reports provide a periodic, standardized view of system health trends over time and are commonly used as a baseline reference architects can compare against after go-live or after major changes. For cloud services, equivalent visibility comes from the relevant service's built-in monitoring and alerting dashboards, which architects must explicitly include in the design rather than assuming parity with on-premise tooling.\n\nA critical architectural discipline is separating OLTP and analytical/reporting NFRs. Transactional response time targets (sub-second to a few seconds) are fundamentally different from reporting or analytics targets (seconds to minutes depending on data volume and aggregation complexity). Architects who apply a single blanket performance target across both risk over-engineering OLTP paths or under-provisioning analytical workloads. Similarly, integration latency budgets must be defined explicitly: if a process spans an on-premise S/4HANA system and a BTP-based side-by-side extension, the end-to-end NFR must be decomposed into a latency budget per hop (application processing time, network transfer, authentication overhead, queuing time), otherwise no single team can be held accountable for the overall target being missed.\n\nFinally, NFRs must be revisited, not just written once. Data volumes grow, integration patterns change, and clean core strategies shift processing between core and extension layers over time. A performance architecture governance practice includes periodic NFR review checkpoints tied to major releases, not only initial go-live, so that sizing and targets remain aligned with actual system growth.

Code example

* Example: simple ABAP snippet to capture and log response time samples\n* for a critical custom transaction, used to validate NFR compliance\n* during hypercare and later regression checks.\n\nDATA: lv_start TYPE timestampl,\n      lv_end   TYPE timestampl,\n      lv_diff  TYPE p DECIMALS 3.\n\nGET TIME STAMP FIELD lv_start.\n\n" ... core business logic under measurement ...\nPERFORM process_sales_order.\n\nGET TIME STAMP FIELD lv_end.\n\nlv_diff = lv_end - lv_start.\n\n" Write to an application log (e.g. via a custom Z-table or standard\n" application log object) rather than only to the screen, so that\n" response time samples can be aggregated later against the agreed NFR:\n" 'Sales order creation must complete under 2 seconds for 95th percentile'\nINSERT INTO zperf_log VALUES @( VALUE #(\n  transaction_id = sy-uname && sy-datum && sy-uzeit\n  duration_sec   = lv_diff\n  process_name   = 'SALES_ORDER_CREATE' ) ).

Real project scenario

During a private cloud S/4HANA migration for a manufacturing client, the project team initially reused ECC-era sizing spreadsheets and estimated CPU needs based on historical anyDB benchmarks. Load testing revealed that batch closing jobs finished faster than expected due to HANA's columnar processing, but a custom Fiori app performing row-by-row postings was far slower than the stated 2-second NFR under concurrent load. The architecture team had to explicitly decompose the NFR into database time, application server processing time, and OData serialization time, discovering the bottleneck was inefficient ABAP loop-based database access rather than infrastructure sizing, which led to a code remediation rather than additional hardware.

Common mistakes

• Copying ECC-era sizing assumptions directly into S/4HANA design without revalidating against HANA's memory and processing model.\n• Defining performance NFRs only as averages, ignoring tail latency (95th/99th percentile) that drives real user complaints.\n• Treating S/4HANA Public Cloud sizing the same as on-premise, when compute sizing is largely provider-managed and the real focus should be extension footprint and integration volume.\n• Setting one blanket response time target for both OLTP and analytical/reporting processes.\n• Failing to decompose end-to-end NFRs across integration hops in hybrid landscapes, leaving no team accountable for the total latency budget.\n• Writing NFRs once at project start and never revisiting them as data volume and usage patterns grow.

Best practices

• Express performance NFRs as testable statements with load conditions, percentile targets, and time windows, not vague terms like 'fast'.\n• Revalidate sizing assumptions per deployment model instead of reusing legacy anyDB-based rules of thumb for HANA-based systems.\n• Separate OLTP and analytical/reporting NFRs explicitly in design documentation.\n• Decompose end-to-end latency budgets across each hop in hybrid or side-by-side extension scenarios.\n• Use existing monitoring tools (workload analysis, database performance views, periodic health reports) to establish and track a real baseline rather than relying on assumptions.\n• Schedule periodic NFR review checkpoints tied to major releases or significant data growth, not only initial go-live.

Interview angle

Interviewers at architect level often ask candidates to define a performance NFR for a given business scenario and then explain how they would validate it across deployment models. Strong answers distinguish OLTP versus analytical targets, mention percentile-based targets rather than averages, and explicitly discuss how sizing responsibility shifts between on-premise, private cloud, public cloud, and BTP services rather than giving a one-size-fits-all answer.