Application performance is one of the key CSF's of an SAP BPC implementation however, aside from employing best practice principles in terms of development, no one can accurately predict how well, or more importantly how badly, an application will perform in the real world. It is often the case that the frailties of application are exposed during a go-live scenario when it might be considered too late to be able to rectify issues that cause performance degradation, either at the application or environment level. SAP BPC has numerous guidelines on performance however, these are normally generalised and cannot be accurately applied to a specific client solution.
Whilst best endeavours may be made to ensure optimal performance, the only way to prove the applications workability is to put it through a stress and volume test scenario.
Why should we test for performance?
In simple terms, it is normally expected that a best of breed solution like SAP BPC will run within 'accepted' performance criteria. The issue is that these criteria are often not quantified accurately by the project team, leading to disputes in terms of what is acceptable in performance terms.
The questions that should be asked are around the following...
What should we expect in terms of performance?
What criteria should we be setting? And...
How do we intend to measure the performance?
The proposal should detail the testing scenarios, which should mirror key business processes and provide realistic expectations in terms of performance for these areas through a combination of stress and volume testing methods. The proposal should cover areas that the project team have earmarked as being complex, or volume intensive, during the realisation phase. For example, Commercial Planning down to SKU level, or multi-currency consolidations involving detailed automatic adjustment calculations and/or complex default logic.
Which approach is best suited?
In my opinion, clients should be encouraged to include a Stress and Volume Testing Add-On for SAP BPC deployments. The purpose of the add-on is to run a realistic simulation of expected workload of the SAP BPC solution to test the solution's scalability as well as providing answers to the following questions:
Is the solution capable of handling the estimated production level transactions volumes within the available time frame?
Was the hardware sizing done accurately?
Which component of the system limits the number of concurrent users?
Are Application Servers and Database Servers configured accurately to withstand desired number of processes or requests?
What benefits would you derive from testing?
There are numerous benefits, both quantitative and qualitative, to be gained by adopting a Stress and Volume testing programme. It has at its core the ability to test scalability of the application and environment. It will inform you of how well your application performs in a real life scenario and can identify key areas of weakness in your application, leading to further analysis of how these can be remedied. It can help you understand how your users will be impacted by SAP BPC before they get to use it 'in anger', and thus providing the ability to be forewarned of performance issues, and being able to investigate possible solutions prior to UAT or User Training.
During a recent deployment of the Stress and Volume Testing Add-on for one of our larger clients, what was interesting was that the volume testing exposed a series of consecutive bottlenecks that were virtually hidden from the development team. Once unearthed, we were able to resolve the bottlenecks sequentially and thus managed to overcome the relevant performance issues. This exercise demonstrated the value of doing the stress test, as if we had left it until go-live, we would have wasted a significant amount of time working through the issues.
Who benefits from this exercise: IT or Finance?
The easy answer is both. The CIO is likely to be concerned about the suitability of the technical environment and scalability, whereas the CFO will be concerned that the application he/she has sponsored does not meet the objectives originally set, and will want to ensure that the user adoption is not impeded by performance blips.
In summary, I believe organisations would benefit greatly from investing in a stress & volume testing exercise. The process allows the project team to decipher problem areas well in advance of the application rollout. It also provides an opportunity to resolve system issues before users get their hands on the application, as typically we would aim to engage in such an exercise before the UAT stage of a project.
The knowledge gathered from this exercise can also have an influence over the future direction of the reporting solution, in that if we are aware of performance bottlenecks with certain elements of the application, we will be mindful of the limitations with regard to future expansion of these areas.