Summary
SAP has tried to make a science out of the sizing process, especially for SAP R/3 systems. However, there are so many influences from the application configuration, that the process seems more like magic at times. This chapter presented a few practical ways to apply the sizing methods for estimating future hardware requirements based on the expected business process requirements. Here are some of the important points:
There are two types of sizings: new requirements or resizing/upgrade requirements. Sizing for new requirements is usually based on making a theoretical estimate. Resizing or upgrading the SAP software release is done only with measurements of the current load or utilization.
A theoretical sizing estimate makes many assumptions that can apply very well to ~80% of the sizing projects. However, ~20% of the sizing projects require expert sizing, for which standard tools do not apply.
To perform a theoretical estimate of the business requirements, consider the document-based sizing approach for more accuracy.
One of the primary goals of the sizing process is to determine the peak processing period and to propose a hardware configuration for that. Peak processing periods can be driven by online users during the day or during a monthly batch process. This is specific to each customer's document processing volume.
With a highly customized business process, the standard sizing approaches and assumptions about peak load will not apply. In these situations, a measurement or performance evaluation should be made of the sample customized ABAP code to determine a customer-specific load factor for sizing purposes.
Data for making a sizing can be collected via a questionnaire from the appropriate persons.
These include the SAP project manager(s), the department managers for the functional areas, and the IT manager for the infrastructure and service level requirements.
Average response time for a sizing usually specifies the dialog response time during the main online timeframe. Response times of batch and update processes or different periods are not considered.
The throughput of the SAP system is typically measured in SAPS, standard transactions per hour, or dialog steps per hour. A system with high throughput is needed for handling the peak processing periods.
Correlation to TPC-C is sometimes useful for comparing sizing proposals from different vendors.
Performance guarantees, if needed, are best made as service level agreements based on measured load.
Estimating the business processing requirements for an SAP R/3 system is an established practice. Estimating the needs of a SAP BW system requires a more practical approach with custom performance measurements.