1

2
Sizing is always based on assumptions!

3
4
KEY LEARNIGNS:
1) There is an initial and productive sizing
2) Sizing is an iterative process; it should take place in the whole software
lifecycle
3) Sizing even if customer is already productive

5
Please note: It is important to know that in case of productive sizings, the current
system utilization needs to be analyzed and measured first and then the additional
load can be added to the current system requirements

6
7
8
Sizing as a rule of thumb: assuming you have seen a new SAP product and you
would like more or less how much hardware I have to acquire.

Example: A daily newspaper expects 5000 ads per week to process; in a 5 day
week, you have 1000 ads per day. You could assume that there a peak times where
more ads needs to be processed. Let‘s assume 2000 adds per day. Usually a working
day has 8 hours. That means that we have to process 250 ads per hour. A
advertisement usually contains only text. Therefore, in general not very complex.

Solutions:
- 1 database access needs normally between 1-5 milliseconds, the maximal response
time of a server is approx.. 1 second.  Therefore: Approx. 1 second per process step
- Assuming that creating a advertisement includes max. 5 steps per transactions, you
would have the following calculation: 250 ads * 5 steps * 1 sec = 1250 seconds
- The CPU capacity of a CPU in seconds is 3600 CPU seconds  from this you see that
one CPU would be sufficient to cover these business processes

Resume: no complex assumptions. Very straight forward. With simple assumptions, you
can easily get a first sizing result

9
10
11
12
13
Let’s have a look at the customer steps in coming to final sizing recommendation.
First of all, they fill in a Quick Sizer project. The input for the Quick Sizer project is
always provided by the customer, typically by people from the business areas.

Sizing is an iterative process over time, meaning that based on the available
business information the sizing input can differ and gets more precise over time.
The more detailed the customer can predict its usages and volumes of processed
data, the more accurate the sizing answer will be. The customer defines the
business need by describing volumes of data and business processes together
with timeframe requirements for regular and peak usages.

Based on the calculated resource requirements, the hardware providers makes

different offers to the customer and communicate costs! They also suggest
configurations and hardware landscapes (including possibilities for virtualization).

The customers can cross-check hardware requirements using results from the
SAP Standard Application Benchmarks and finally can accept the offer or reject it.
If, as a result of using SAP's sizing tool "Quick Sizer", a sizing table for a particular
solution suggests a configuration of 10,000 SAPS, you can check the SD two-tier
benchmark table for a sample configuration.

14
15
Some factors can be predicted, others not.
1. Technology partners: they offer the processor, disk and network technology.
Hardware and Configuration must scale; this is something that can not be predicted
by SAP. This must be guaranteed by hardware partners.
2. SAP offers different business software with different releases, that has to run
efficiently on different hardware platforms. Depending on the release or if it is OLAP
or OLTP the software behave differently
3. Customer: System settings are done by customer. SAP has no influence on that
(Cache) In our sizing guidelines, the tests run on optimal settings and conditions.
SAP has no influence on custom coding, 3rd party. SAP tries to find answers by
intelligent questions in the Quick Sizer about data volume, disk growth and user
behavior.

16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32