Skip to main content
Discuss the technical scope

Working approach

How we work on SAP® software topics, and what we do not claim

This page describes the principles behind Castintech’s technical work on SAP® software topics. There is no individual, no project history and no promised outcome here. As a team, we set out how we approach a technical question and what we do not say.

  • Prepared by Castintech
  • Last verified 23 September 2026
  • 7 min read
  • Sources

On this page

Sections

Why do we define the problem in context first?

The same technical symptom can call for different decisions in different contexts. A slow report might be an output one person uses at month-end, or a step that holds up orders all day. So before looking for a fix, we pin down in writing which process the problem appears in, for whom, when and at what scale.

Questions answered at the start:

  • Which business process and which users does the problem affect?
  • Since when has it been seen, and what changed before that?
  • What would need to be observed for the problem to count as solved?
  • Who will decide on it?

How do we separate assumptions from evidence?

Every technical finding is written down together with the type of evidence behind it: measured, confirmed by official documentation, confirmed by the business owner, or assumed. Assumptions are not deleted; they stay as a separate list in the decision log, each with a note on how it will be confirmed.

If a decision later turns out to be wrong, you can see which assumption failed.

This helps in meetings too. Does “this object is not used” rest on a usage record, on someone’s memory, or on a guess? Once the type of evidence is written down, the discussion moves from opinions to evidence.

Why do we check product and release scope every time?

A capability with the same name can have a different scope depending on the product and the release. For example, according to SAP documentation, the checks offered by the SAP tool that inspects code written in the ABAP® programming language depend on the release [1][2]. SAP’s clean core level model is defined in the context of SAP Cloud ERP Private [3].

So before recommending a tool, an interface or a model, we confirm that it is within the product, release and licence scope of the landscape in question. Where scope cannot be confirmed, we record it plainly as “not verified” rather than assuming it and moving on.

Why do we not report outcomes that were not measured?

If the effect of a change was not measured before and after under the same conditions, we do not give an outcome figure. Even phrases such as “faster” or “fewer errors” can mislead a management decision when there is no baseline. Where measurement is not possible, we say so and suggest which measurement could be made.

Until a measurement is made, we write the effect down as a hypothesis. Our method for performance questions is set out in Gathering evidence in a performance investigation.

The performance evidence chain: a symptom becomes a measurement question, a baseline is measured, one change is made and its effect is re-measured under the same conditions. Start: the symptom; “the system is slow” is an observation, not a measurable question. The symptom is turned into a measurement question with five items: operation or scenario, user group, time window, expected and observed duration, business impact. Next, the baseline is built as a distribution, not a single measurement: a representative histogram marked with the average, a percentile and the longest duration. The call chain splits time into database access, application logic, external system calls, network, locks and resource waits, and user interface; one item is marked as the hypothesis item X. Decision point 1: bottleneck or symptom? Hypothesis: if X is reduced, total time should drop; X is measured in isolation. If not confirmed, a dashed return path goes back to the call chain and the investigation moves to the next item. If confirmed, one change is made. It is then re-measured under the same conditions; this frame has the same width and axis as the baseline, the baseline silhouette is shown dashed only for comparison, and no new result is drawn. The bracket joining the two frames shows the same conditions: concurrent load and running batch jobs, data volume and distribution, selection criteria, cache state and the same protocol. Boundary: a measurement in a test environment gives a direction; it is not evidence of live behaviour. Decision point 2: is the effect proven under the same conditions? If not, no result is claimed and the effect stays a hypothesis; that branch ends there. End: if proven, a reproducible evidence pack; raw results are kept apart from interpretation, and the difference within which two results count as the same is defined before measuring. Apart from the single return path of the bottleneck hypothesis there is no loop. Chart scales are representative, not measured values. On mobile the diagram reads as three panels in order: 1/3 symptom, measurement question and baseline, 2/3 context, call chain and bottleneck, 3/3 one change, re-measure and evidence. Colophon: Castintech, D4, September 2026; technical explanatory diagram, not an SAP® product interface. D4 · PERFORMANCE INVESTIGATION The performance evidence chain Shows how measuring first, making a single change and re-measuring under the sameconditions turns a performance result into evidence. decision point open node outcome main path branch exception path evidence scope boundary representative scale Symptom “The system is slow” is anobservation, not a measurablequestion Measurement question Operation or scenario User group Time window Expected and observedduration Business impact Baseline A distribution, not a single measurement: average,percentiles, longest duration average percentile longest time Representative scale; not measured values Where is the time being spent? Time is split into items along the call chain Database access Application logic X External system calls Network Locks and resource waits User interface Representative scale; not measured values 1 Bottleneck or symptom? Hypothesis: if X is reduced, total time should drop. X ismeasured in isolation. If not confirmed: the bottleneck is elsewhere, and theinvestigation moves to the next item IF CONFIRMED One change One change at a time, with its reason Re-measure under the same conditions Same protocol and same distribution statistics; sideeffects are checked too baseline, for comparison the new distribution ismeasured with the sameprotocol time Representative scale; not measured values SAME CONDITIONS Runtime and datavolume context Concurrent load andrunning batch jobs Data volume anddistribution Selection criteria Cache state Same protocol: how it isstarted, number ofrepetitions, summarystatistic A measurement in a testenvironment gives adirection; it is not evidenceof live behaviour. 2 Is the effect proven under the sameconditions? If not proven: no result is claimed, and the effectstays a hypothesis PROVEN Reproducible evidence pack Measurement question Environment andconditions Protocol Baseline Time breakdown Hypotheses and theirresults The single change made After measurement andside-effect check Limits and openassumptions Raw results are kept apart from interpretation; the difference within which two results countas “the same” is defined before measuring. Castintech · D4 · EN · September 2026 Technical explanatory diagram; it is not an SAP® product interface.
  1. D4, panel 1/3: the symptom “the system is slow” becomes a measurement question with five items, and the baseline is set as a representative distribution. On mobile the diagram reads as three panels in order: 1/3 symptom, measurement question and baseline, 2/3 context, call chain and bottleneck, 3/3 one change, re-measure and evidence. Panel 1/3. Start: the symptom; “the system is slow” is an observation, not a measurable question. Measurement question: operation or scenario, user group, time window, expected and observed duration, business impact. The baseline is built as a distribution; a representative histogram marked with the average, a percentile and the longest duration. Measurement conditions are recorded (2/3). The chart scale is representative, not measured values. Colophon: Castintech, D4, September 2026; technical explanatory diagram, not an SAP® product interface. D4 · PERFORMANCE INVESTIGATION 1/3 The performanceevidence chain Shows how measuring first, makinga single change and re-measuringunder the same conditions turns aperformance result into evidence. main path evidence representative scale Symptom “The system is slow” is anobservation, not a measurablequestion Measurement question Operation or scenario User group Time window Expected and observedduration Business impact Baseline A distribution, not a singlemeasurement: average,percentiles, longest duration average percentile longest time Measurement conditions arerecorded (2/3). CONTINUES IN 2/3: CONTEXT,CALL CHAIN AND BOTTLENECK Representative scale; not measuredvalues Castintech · D4 · EN · September2026 Technical explanatory diagram; it is not anSAP® product interface.
  2. D4, panel 2/3: the same conditions are recorded, time is split along the call chain, and a hypothesis measurement separates the bottleneck from the symptom. On mobile the diagram reads as three panels in order: 1/3 symptom, measurement question and baseline, 2/3 context, call chain and bottleneck, 3/3 one change, re-measure and evidence. Panel 2/3. Same conditions: runtime and data volume context; concurrent load and batch jobs, data volume and distribution, selection criteria, cache state and the same protocol. The call chain splits time into database access, application logic, external system calls, network, locks and resource waits, and user interface; one item is the hypothesis item X. Decision point 1: bottleneck or symptom? X is measured in isolation. If not confirmed, a dashed return path goes back to the call chain; if confirmed, the path continues in 3/3. Colophon notes: the scale is representative; a test-environment measurement is not evidence of live behaviour. Colophon: Castintech, D4, September 2026; technical explanatory diagram, not an SAP® product interface. D4 · PERFORMANCE INVESTIGATION 2/3 Context, call chain andbottleneck decision point exception path scope boundary SAME CONDITIONS Runtime and data volumecontext Concurrent load and runningbatch jobs Data volume and distribution Selection criteria Cache state Same protocol: how it isstarted, number of repetitions,summary statistic Where is the time beingspent? Time is split into items alongthe call chain Database access Application logic X External system calls Network Locks and resource waits User interface 1 Bottleneck orsymptom? Hypothesis: if X is reduced, totaltime should drop. X is measuredin isolation. If not confirmed: thebottleneck is elsewhere, andthe investigation moves to thenext item IF CONFIRMED CONTINUES IN 3/3: ONECHANGE, RE-MEASURE,EVIDENCE Representative scale; not measuredvalues A measurement in a test environmentgives a direction; it is not evidence oflive behaviour. Castintech · D4 · EN · September2026 Technical explanatory diagram; it is not anSAP® product interface.
  3. D4, panel 3/3: after one change the same axis is measured again; a proven effect becomes a reproducible evidence pack, an unproven one stays a hypothesis. On mobile the diagram reads as three panels in order: 1/3 symptom, measurement question and baseline, 2/3 context, call chain and bottleneck, 3/3 one change, re-measure and evidence. Panel 3/3. One change: one change at a time, with its reason. Re-measure under the same conditions; the baseline silhouette is shown dashed only for comparison and no new result is drawn. Decision point 2: is the effect proven under the same conditions? If not, no result is claimed and the effect stays a hypothesis. If proven, a reproducible evidence pack; raw results are kept apart from interpretation and the tolerance is set in advance. The chart scale is representative. Colophon: Castintech, D4, September 2026; technical explanatory diagram, not an SAP® product interface. D4 · PERFORMANCE INVESTIGATION 3/3 One change,re-measure, evidence decision point outcome exception path scope boundary One change One change at a time, with itsreason Re-measure under the sameconditions Same protocol and statistics;side effects are checked too. baseline, for comparison time the new distribution is measuredwith the same protocol Same conditions: the contextin 2/3. 2 Is the effect provenunder the sameconditions? If not proven: no result isclaimed, and the effectstays a hypothesis PROVEN Reproducible evidencepack Measurement question Environment and conditions Protocol Baseline Time breakdown Hypotheses and their results The single change made After measurement andside-effect check Limits and open assumptions Raw results are kept apart frominterpretation; the tolerance for“the same” is set in advance. Representative scale; not measuredvalues Castintech · D4 · EN · September2026 Technical explanatory diagram; it is not anSAP® product interface.
Text description of the diagram

Start: the symptom; “the system is slow” is an observation, not a measurable question. The symptom is turned into a measurement question with five items: operation or scenario, user group, time window, expected and observed duration, business impact. Next, the baseline is built as a distribution, not a single measurement: a representative histogram marked with the average, a percentile and the longest duration. The call chain splits time into database access, application logic, external system calls, network, locks and resource waits, and user interface; one item is marked as the hypothesis item X. Decision point 1: bottleneck or symptom? Hypothesis: if X is reduced, total time should drop; X is measured in isolation. If not confirmed, a dashed return path goes back to the call chain and the investigation moves to the next item. If confirmed, one change is made. It is then re-measured under the same conditions; this frame has the same width and axis as the baseline, the baseline silhouette is shown dashed only for comparison, and no new result is drawn. The bracket joining the two frames shows the same conditions: concurrent load and running batch jobs, data volume and distribution, selection criteria, cache state and the same protocol. Boundary: a measurement in a test environment gives a direction; it is not evidence of live behaviour. Decision point 2: is the effect proven under the same conditions? If not, no result is claimed and the effect stays a hypothesis; that branch ends there. End: if proven, a reproducible evidence pack; raw results are kept apart from interpretation, and the difference within which two results count as the same is defined before measuring. Apart from the single return path of the bottleneck hypothesis there is no loop. Chart scales are representative, not measured values. On mobile the diagram reads as three panels in order: 1/3 symptom, measurement question and baseline, 2/3 context, call chain and bottleneck, 3/3 one change, re-measure and evidence. Colophon: Castintech, D4, September 2026; technical explanatory diagram, not an SAP® product interface.

How do we keep decisions reversible and traceable?

Each significant technical decision gets a short decision record: what was decided, which options were considered, what evidence and assumptions it rests on, who approved it, and what would be done if it had to be reversed. Changes without a defined way back are split into smaller steps that can be checked.

When a decision is questioned months later, this record means nobody has to reconstruct the reasoning. If the same topic comes up again, the discussion starts where the record left off, not from scratch.

How can the technical team and management talk about the same issue?

A technical finding becomes clear to management once it is turned into four questions: which process is affected, what happens if the risk materialises, what are the options to reduce it, and which decision is needed from management? Technical detail is attached to the decision rather than lost. The decision itself is written in terms of business impact and options.

The translation runs both ways. Management’s priorities and the level of risk it can accept are also passed to the technical team in plain terms, so the technical team does not have to guess business priorities on its own.

How are documentation and handover handled?

The documents we leave at the end of a piece of work are written so they can be used without us. The aim is that whoever runs or later changes the system can find the reasoning, open risks and owners in one place. They are written for the team that will use them. A handover is expected to include:

  • the decision record and the evidence behind it
  • open assumptions and the steps to confirm them
  • known risks and monitoring suggestions
  • what is needed to run it: what to monitor where, and what to do when something fails
  • a named owner for each topic

What do we not claim?

  • We do not claim that the approach in this section will deliver any particular timeline, cost or performance outcome.
  • We do not present an unmeasured gain as a result.
  • We do not say that a code check tool or a dashboard produces a decision on its own.
  • We do not assume that an approach works the same way in every product, release and installation.
  • We do not present an interpretation that is not in SAP documentation as SAP’s view; we write our own interpretation separately from the official definition.
  • We do not say that general guides replace a technical assessment specific to an organisation.
  • We do not use the names of individuals, customers or projects in this section; the content is a general technical approach and does not rest on the results of past work.

Frequently asked questions

Is this section a sales page?

No. This section explains our technical approach and its limits; it contains no commercial proposal. The aim is to let people deciding on SAP software topics see in advance what they can expect from a technical assessment.

What information should be ready before an assessment starts?

The products and releases in scope, the processes affected and their owners, a short list of known issues, and existing technical documentation. Gaps are not a problem; they are recorded at the start and the assessment is planned around them.

Why don’t you give outcome figures?

A figure means something only if it rests on a before-and-after measurement taken under the same conditions. A figure on a general page does not reflect the conditions in your landscape and can become a misleading anchor for the decision.

Do general guides replace an organisation-specific assessment?

No. The guides describe which questions to ask and which evidence to gather. The answers depend on each organisation’s product scope, processes and data.

Why are assumptions kept in the decision record?

Because every decision contains some assumptions. When they are written down, it is quick to see which decisions need revisiting once conditions change.

Other pages in this section

Sources

Bracketed numbers in the text refer to the sources below.

  1. 1

    Quality Checking with the ABAP Test Cockpit (ATC) — help.sap.com, ABAP platform documentation.

    https://help.sap.com/docs/ABAP_PLATFORM_NEW/ba879a6e2ea04d9bb94c7ccd7cdac446/62c41ad841554516bb06fb3620540e47.html

    Source date: document version 2025 FPS01 (February 2026) Last verified: 23 September 2026

  2. 2

    Usage Scenario and Technical Requirements — help.sap.com, ABAP platform documentation.

    https://help.sap.com/docs/ABAP_PLATFORM_NEW/ba879a6e2ea04d9bb94c7ccd7cdac446/7f9d7a446bb74a8c8e4970bcfbeb1f99.html

    Source date: document version 2025 FPS01 (February 2026) Last verified: 23 September 2026

  3. 3

    Clean core extensibility: Creating scalable, upgrade-ready extensions for the Autonomous Enterprise — SAP white paper, section 3.3 (pp. 19–22).

    https://www.sap.com/docs/download/2024/09/20aece06-d87e-0010-bca6-c68f7e60039b.pdf

    Source date: no explicit publication date in the document; p. 52 shows “(08/26)” and “© 2026” Last verified: 23 September 2026

Last verified: 23 September 2026

SAP and ABAP are the trademarks or registered trademarks of SAP SE or its affiliates in Germany and in other countries.

This content has been independently prepared by Castintech.

Independence note

  • Castintech does not claim any partnership, authorization, endorsement or sponsorship relationship with SAP SE.
  • SAP and the SAP product names mentioned on this page are trademarks of SAP SE or its affiliates.
  • The work Castintech offers is independent technical consulting and support.

Cookies and measurement

Apart from what the site needs to work, measurement or advertising tags only run if you allow them. No measurement tags are active on this site right now. Details