Applying the Right Sizing Method and Using the Right Sizing Tool
In this blog post, I would like to describe the different sizing methods at SAP and want to provide some guidance about the usage of the different sizing tools. Focus of this blog entry is the sizing of SAP S/4HANA. However, for the sake of completeness some general definitions and methods which are not primarily in the focus of SAP S/4HANA are being introduced as well.
Before I start explaining the different methods and tools, I would like to provide a short introduction into hardware sizing in general. It’s important to understand that conducting an adequate sizing exercise is only possible when a software application is scalable. Within SAP, we make sure that every software application that is shipped to the market is scaling. The purpose of hardware sizing is to determine the hardware resources necessary to process performance-critical business processes, thus preventing hardware resources from becoming bottlenecks. In general, sizing is the process of translating business requirements into hardware requirements. In this context, sizing means determining hardware requirements, such as physical memory, CPU power (SAPS), disk I/O, disk space, and network bandwidth to make sure that software applications run smoothly.
For SAP S/4HANA, there are different deployment models available:
- SAP S/4HANA Cloud
- SAP S/4HANA Cloud, private edition
- SAP S/4HANA On-Premise
In the following I would like to discuss these topics more in detail:
- What are the different sizing methods at SAP?
- Why do you need a sizing in the Cloud?
- Which sizing tools should be used?
- How and why to size SAP S/4HANA Cloud?
- How and why to size SAP S/4HANA Cloud, private edition?
- How to size SAP S/4HANA On-Premise?
- Where to get more information about sizing at SAP?
What are the different sizing methods at SAP?
Generally, we differentiate between Greenfield, Brownfield and Expert Sizing.
Greenfield Sizing: If you want to size a new SAP applications from scratch.
Brownfield Sizing: If you have an SAP system running that you want to extend with new functionality (Delta Sizing – mix between greenfield and brownfield sizing) and/or add new users (Re-Sizing) or migrate to SAP HANA.
Expert Sizing: If you are working in a large company with complex business structures, and/or custom coding, you should perform an expert sizing.
More information about the different sizing methods can be found here.
Why do you need a sizing in the cloud?
You may ask yourself why sizing in the cloud is required at all. Customers usually subscribe for specific cloud offerings and in general they are not interested to know how many application servers they need or how much memory they have to allocate.
Traditionally, sizing information is provided to customers on www.sap.com/sizing and customers are conducting the sizing exercise by themselves since they best know their business processes. Once the sizing is done, the hardware vendors or IaaS providers will provide a system that fulfils the customers’ requirements.
For SAP S/4HANA Cloud, SAP as the SaaS provider operates the customer’s SAP S/4HANA tenant in the cloud. In that sense, SAP takes care of sizing and provisioning. But customers are still interested in sizing because this directly impacts the pricing calculation.
Which sizing tools should be used?
If you plan to perform a greenfield sizing, you should use the Quick Sizer or apply the sizing guidelines. Depending on the deployment model, there are different Quick Sizer versions available:
HANA-based Quick Sizer: Please use this version, if the product that you want to size uses SAP HANA as database, e.g., SAP S/4HANA, SAP BW/4HANA, etc. In addition, the HANA-based Quick Sizer can be used to conduct a sizing for SAP S/4HANA Cloud, private edition, which is part of RISE with SAP.
HANA-based Cloud Quick Sizer: Please use this version, if the product that you want to size shall run in the Cloud; e.g. SAP S/4HANA Cloud and SAP Data Warehouse Cloud
Non-HANA-based Classic Quick Sizer: Please use this version only, if the product that you want to size shall run on a non-HANA database.
If you plan to perform a brownfield sizing, you should apply a different sizing approach. In case you want to extend your system by additional users (also called Re-Sizing) or additional functionalities (also called Delta Sizing), the following procedure is recommended:
- Monitor CPU utilization, table growth, and memory use
- Relate it to a meaningful business entity, such as the number of concurrent users or the number of active projects
- Different procedures according to goals
- Re-sizing: Add the load coming in through the additional users and projects causing the same load structure
- Delta sizing: Treat like a new sizing (Quick Sizer and/or sizing guidelines) and add calculated load
- Judge whether your current hardware is sufficient, or whether you may need to buy new hardware
Brownfield sizing can also be the migration from an SAP NetWeaver source system to SAP HANA. The SAP S/4 HANA sizing report /SDF/HDB_SIZING (SAP note 1872170) should be used to estimate the hardware requirement (HANA memory, disk space and SAPS) if you plan to migrate your SAP NetWeaver-based ECC system to SAP HANA.
If you want to estimate the hardware requirements of an SAP Business Warehouse system after migration to SAP HANA, you should run the BW sizing report (SAP note 2296290).
The following picture summarizes the different migration scenarios and provides an overview about the relevant sizing approach:
Typically, in an expert sizing, more profound analyses on the results of a tool-based sizing (Quick Sizer, Sizing Reports, etc.) are performed. There are no standard tools available to conduct expert sizing, but there is a large range of possibilities for such additional analyses.
In case of very complex sizing tasks (e.g. when multiple products / components are involved in a sizing exercise) a detailed exploration of some core business processes may be required, both on functional and technical level. More information on expert sizing can be found here.
How and why to size SAP S/4HANA Public Cloud?
SAP S/4HANA Public Cloud provides net new customers or those who wish to move to a greenfield implementation to embrace the next generation cloud ERP solution as a service.
SAP S/4HANA Cloud is a complete modern SaaS ERP solution with full public cloud benefits. For SAP S/4HANA Cloud, SAP as the SaaS provider takes care of sizing and provisioning. However, sizing information is still important for customers of SAP S/4HANA Cloud. As S/4HANA Public Cloud is always a greenfield implementation, the following sizing description only focuses on greenfield sizing. In a pay-per-use scenario some forecast calculations are necessary to decide on the most adequate subscription model. To predict the SAP HANA memory required by an application within the customer’s business context customers should use the HANA-based Cloud Quick Sizer:
As a first step, you have to determine the number of Full User Equivalents (FUEs) into the tool. After chosing your relevant business scenarios, you need to insert your relevant business input (e.g. number of concurrent user and/or number of business objects that are processed within a certain time period). Once you are finished with that, the Quick Sizer calculates a result for HANA Memory and a tier number for cloud pricing which can be used as input for the calculation of the licensing costs. The bigger the HANA memory footprint is, the larger is the tier that is needed. In some situations, there might be a mismatch between the entered FUEs and the expected business volume which was entered in the Quick Sizer questionnaires. In that case, Quick Sizer will display a warning message and the additional resource requirements to cover the load of the result are indicated in Quick Sizer.
How and why to size SAP S/4HANA Cloud, private edition?
SAP S/4HANA Cloud, private edition (PCE) offers a rapid conversion of existing SAP ERP/ECC environments to a modern, cloud-based architecture. Customers subscribing to SAP S/4HANA Cloud, private edition receive the full S/4HANA scope. The SAP S/4HANA Cloud, private edition is the gradual transformation to a pure SaaS landscape.
For S/4HANA PCE, there is also the possibility for a system conversion. Hence, a sizing approach is available and will be presented below.
Due to the fact that customers can get the full, extensive ERP functionality, the recommendation is to use the HANA-based Quick Sizer. Please note that not all applications are part of Quick Sizer. If you can’t find the application in the Quick Sizer, you should also have a deeper look at the S/4HANA sizing guidelines.
If you want to migrate your landscape from an ECC system to SAP S/4HANA Cloud, private edition you can use the sizing report (/SDF/HDB_SIZING) to determine the expected HANA memory size.
How to size SAP S/4HANA On-Premise?
On-Premise customers should use the HANA-based Quick Sizer for greenfield sizing and the sizing report (/SDF/HDB_SIZING) for migrations (customers moving their BW to HANA have to use BW sizing report).
The HANA-based Quick Sizer delivers a wide range of relevant sizing results, such as application and database memory and SAPS, Disk I/O and disk space. These results help you to pinpoint the hardware requirements for your specific implementation.
Where to get more information about sizing at SAP?
All sizing relevant information and access to Quick Sizer, Sizing Guidelines, Sizing Reports, etc. can be found on www.sap.com/sizing. You can also find more information in the Sizing Decision Tree.
Just wondering how SAP S4HANA Cloud calculating “Estimated Memory size of business data”, can we not build an on-premise/hyperscaler system using this size? “Estimated Memory size of business data” In other words, how SaaS model skips meta/row store data into consideration?
thanks for your question!
The Cloud Quick Sizer is only for new systems (greenfield). If you already have a system which you want to deploy in the S/4HANA Cloud, you can use the sizing report. Please note that the output "Estimated Memory size of business data" is preliminary used as input for the pricing. It's not the memory size which is required to build a new system.