One of the questions we hear a lot at the beginning of our projects is the one about the sizing of the mobile system landscape. In this blog, we want to discuss which factors are important for the answer. 

Sizing the hardware of mobile applications is not a simple topic. It needs to be done for all layers of the mobile landscape. If you have a mobile middleware and SAP as backend, we should consider the following:

• How many users will connect via their mobile device?
• How many concurrent mobile users will we have? 
• What is the total data volume on the middleware?
• What is the maximum data volume per mobile device?
• What is the delta that is synchronized per sync cycle?
• How complex is the data model? The more complex it is, the more power the middleware needs to compute the delta
• How much data is sent back from the mobile client to SAP? 
• What type of data is sent back to SAP? Orders, Notifications, Equipments, Time Confirmations or something else? The time to update or create objects in SAP is different for each object type, therefore we need to take this into consideration.
• Is there any need to up- and download documents? What´s the average size per sync (up- and download)?
• Is there a pool of documents which needs to be transferred to the mobile device initially to be kept offline?

When implementing a mobile solution for maintenance or customer service, you do not only need to do a sizing of the middleware, but also need to consider the additional load on the SAP system itself. If your users accessed SAP via the GUI before, this load will be reduced. But you add more stress to the system via the mobile landscape. Don’t forget to factor this in!

Depending on your data volume, there is another component that needs sizing: your network. Especially if you send a massive amount of binary attachments and your users usually sync at the same time, the network can be the bottleneck. 

Bad sizing of the network and SAP will not only harm your mobile users, but also the dialog users in front of the SAP GUI. More potential for angry users ;-)

To do a good and correct sizing, it is important to understand your systems architecture in detail. For our MobiLink based solution SAM, it is most important to give the middleware database enough power, as in our scenario the database is doing all the heavy lifting. SAP does not need a lot of additional resources with SAM, as there is limited load on top. Looking at the SAP Work Manager however it is the opposite - the Work Manager adds lots of load on SAP and very little on the middleware application server and database. Therefore, you should worry about SAP in this case, not the mobile landscape.

Usually, we do not do the detailed sizing of the productive system at the beginning of the project. We just setup the development and quality systems and do the proper sizing during the design and analysis phase.

When looking at the numbers, you should also think about future growth - will you add more users in the future? Will your data volume increase? 

Virtualisation took away many of the headaches of sizing. Today, it is much easier to add additional RAM and CPU than in the past.

Like our customers who ask about sizing, you are also not getting an answer with this blog. There is no one-size-fits-all when it comes to the sizing of mobile offline applications. I just wanted to create awareness for the topic. No mobile user will be happy if the synchronization is slow because you did the sizing wrong. Trust me, I have been there …