In my previous post – performance control in SAP project, SAP project performance effort is divided into three important performance areas:
- Capacity planning,
- Application development performance control and
In this post, I would talk more about application development performance control. Application development performance control is to make sure that a program or a solution developed in a SAP project runs as faster as possible in addition to meet quantified performance requirement, uses resources as much as it needs and as less as possible and work well with other solutions. I would cover
- Overview on SAP application development performance effort and
- Performance activities in different SAP project phases.
Application performance control is to focus on performance issue prevention, and earlier detection and solution.
1 Overview on SAP application development performance effort in a sap project
In my view, performance effort in SAP program/solution development can be classified into following areas as showed in figure 1.
Figure 1 SAP application development – Performance Areas
All effort in application development performance control in a project is to focus on:
- Prevention – It is always better that a performance issue never exists in performance requirement definition, in application design or configuration, in program development and in solution deployment. Performance training on performance standards, guidelines, tools/resources and best practice can help to reach this goal.
- Detection – If there is a performance issue, we would like to detect and find this as soon as possible. It saves project cost, effort and synergy to fix a performance concern detected in design phase other than in business acceptance testing or production phase.
- Solution – So we have detected a performance concern, we need to find a way to fix it.
With all those effort, we can be closer to our ultimate performance goal that all SAP application solutions developed by the project have good performance qualities in terms of time, resource and resident-ship.
1.1 Performance training
Teaching a man how to fish is always better than giving him a fish. That is objective of performance training. To achieve this, Performance training would try to equip all developers and business users with performance standards, performance guidelines, performance best practice and performance tools. So the developers know what is expected as well as tools and resources which help them to meet that expectation. For example, SAP developers and business users should be clear on expected performance of a solution which they are responsible for. If you do not know this, then you could not realize potential performance concern or realize a performance issue is happening.
It is important to give necessary performance training end business users as well. Training on business users with specific objective – facilitate performance works which needs business input like performance requirement and avoid un-necessary performance issue due to business users’ improper interaction with SAP system etc.
Some SAP projects often overlook importance of this step. Time/effort invested in this step has a profound effect in and outside of the project – design and code delivered by project would have less performance concern during performance validation – this could reduce rework in the project and possible performance concern in the solution life cycle. Developers and business users can use the performance knowledge in their future works/projects.
Performance training should be given to the project community (such as developers and key business users) after project is kicked off and before any design and development work is started.
Adequate training can help to achieve one of performance goal: performance issue prevention.
1.2 Collect Performance requirement
This step is to collect and clarify business quantify performance requirement as well as needed performance data on project solution – like how critical it is to performance, volume and pattern, frequency, concurrent usage, data retention period etc.. If your project is going to use SAP quick-size for hardware capacity planning, you can refer to performance data collected in that process for application development control.
1.3 Develop performance validation plan
This would include scope, method, tools, measurement, test, who, when, where and processes. Validations in different project phase would be different. Validation in different stage of a solution development cycle would be different. Subsequent section of this post would talk performance validations based on SAP project phases.
Validation scope specifies what is subject to validation:
- Technical deliverable like design document, technical specification, SAP configuration specification and program code developed and
- Function/process scope – all function or selective function.
Validation method specifies how to validate performance:
- Static validation(like technical design review and code review) which has no involved on program/solution execution like technical design document review, and
- Dynamic validation through analyzing program behavior by doing performance testing and tracing.
Measurement is the agreement on when a validation is considered as “successful” without performance concern. For example, static evaluation on design document might be considered successful if no concern is found against performance design guidelines; dynamic validation on a program testing case might be considered successful if it meets runtime, resource usage and residence requirement.
Tools include issue tracking tool, test automation tools, performance monitoring tools, tracing and analysis tool ( SAP ST12, SAP ST05) etc. If it is applicable, this should be specified in the validation plan.
Tests here is about what business scenario should be tested in performance validation.
Who is to specify who should be involved in performance validation. In terms of testing, you need to specify who should prepare the testing case, who should execute the case, who should monitor the case and who should trace and analyze the case and who should track and manage all concerns from validation to make sure they are properly addressed to satisfaction.
When is to specify when a performance validation should happen – Design, BAT and etc..
Where is to specify whether a validation should happen in development box or testing box etc.
The process is to integrate all above components together.
For a single solution development, the performance validation cycle is built into each milestone of a solution development as:
Figure 2 Performance validation cycle for single solution
Performance validation is an iterative process. For example, if a performance issue is detected in performance testing, then we might need to verify the performance requirement again, if design is changed to fix the performance issue, then design needs validation. Technical code introduced needs validation. Performance testing needs to repeat to see where we are standing in terms of performance after change.
Performance test is normally done after functionalities of solution has been tested to work fine by business to avoid rework. For critical and complex solution, performance test and code validation could/should be done earlier since it might take significant time and effort to make it performance compliant.
Performance validation plan for SAP development should be worked with “earlier detection” objective in mind. It should be built into each phase of SAP project life cycle and each milestone of a solution development.
1.4 Execute performance validation plan
Predefined performance validation should be executed without delay so a potential performance issue can be detected earlier.
1.5 Validate solution deployment plan
This is to check whether solution developed by a project is best positioned and integrated into production landscape to achieve load balance and avoid contentions.
1.6 Support and validate solution in production operation
This is to verify how solution is performing in terms of meeting our performance goal and address any production performance incident or potential concerns.
2 Performance activities in different SAP project phases
Above, we talk about performance effort/areas in SAP application development. You might wonder how we can map them into each phase of a SAP development project.
2.1 Preparation/Planning phase
In this phase, an initial application development performance control plan is developed based on nature of SAP project, Performance goals and objectives are established. The performance control plan profiled a list of performance areas and activities needed for a SAP project.
Before the end of phase, performance training should be given to project community so they understand benefits which performance control brings to business and are ready to work on or support subsequent performance works in the project.
2.2 Business Blueprint/Match and Mapping
Performance activities in this phase can include:
- Collect and validate performance data,
- Review and update Performance standards, practice, guideline review etc.
- Review and update Performance validation/control processes review and
- Update Performance control/validation plan.
This is to understand business requirement and map them into corresponding SAP solutions. In this phase, it might be good to define performance questionnaires to facilitate performance data collection. Meantime, it is important to update/define performance standards, performance guidelines, performance best practice and performance tools which should be applicable to the project. Process for performance validation/control should be defined and communicated to the project community such as table/index creation approval , buffering approval process, parallel solution approval process etc.
Performance plan can be updated based on more input from business. For example, initial performance control/validation plan states that key processes needs to be tested without details, you can add/update those details into the plan based on input from this phase. Project budget cannot afford effort to validate all technical designs, the need to select critical/important technical design and validate them arises. So you work with business users to come out “selection criteria” and use that “selection criteria” to choose a project solution whose design should be validated from performance point view. The selection criteria should be define based on how critical a solution is to business in terms of time and level of risk which a solution can bring into the SAP system. Time sensitive, resource extensive program is normally a critical program. Other factors can include complexity of the solution, number of users, frequency etc.
2.3 Realization/Design and construction phase
Performance activities in this phase can include:
- Performance training,
- Performance testing plan,
- Static performance check on solution technical design document,
- Static performance check on technical code and/or configuration,
- Dynamic performance check on solution developed – Performance unit testing and
- Address any known performance issue.
Before any design, configuration and development is committed, performance training should be given to all developers. In this phase, performance training should be focus on performance standards, guidelines, best practices, tools and related performance processes.
Performance testing plan should be defined or tuned in this phase.
Static performance check on technical design documents would be executed in this stage to ensure that technical design follow the performance standards, performance guideline and best practice. This should be executed before actual development is started. Dependent on effort allocation, you might validate technical design on selected business process based on predefined selection criteria
Static performance check on program code/configuration is to make sure program code is in compliance with performance standards, guidelines and best practice. Dynamic performance check is to check performance of program execution. SAP standard tool – code inspector (SAP transaction code – SCI) can be used to facilitate static performance check on SAP ABAP development.
Developer should be responsible for performance of the application he develops. So it is a reasonable expectation that self-check on performance should be carried out by the developer before the solution is passed on to next phase. Since solution in realization/”design and construction” phase is more likely to subject to change than in business accepting phase, having dedicated performance resources to execute performance validation on a full-scale might be premature.
2.4 Final Preparation/SIT, BAT phases
Performance activities in this case can include:
- Performance volume testing based on performance plan,
- Static validation(code review) on program code developed by the project,
- Dynamic validation(testing) on solution which has local development,
- Validation and review system log via SAP workload monitor(SAP transaction code ST03), database monitor(SAP transaction code ST04) and core-dump check(SAP transaction code ST22),
- SAP performance training to end-business users,
- Solution deployment validation,
- Solution readiness check – this is to make sure all performance testing have been completed and all performance concerns have been addressed to satisfactory and
- Address any known application performance issue.
If a solution cannot meet business functional requirement, it would be subject to change. Performance validation should be carried out after solution has passed business acceptance testing to avoid rework. As long as a solution is ready and signed off by business, the solution performance qualities should be validated. So any potential performance issue can be addressed earlier – earlier is always better than later in this case.
Validate and review system log should be done regularly. If there is a clear cut between SIT and BAT phase, ST03, ST04 and ST22 check should be done at least once after completion of each phase.
When we validation a solution performance quality, we need to remember performance has three qualities –time, resource usage and resident-ship not just runtime. So a program has “good’ runtime quality but it is using too much resource like memory than what it really needs, it can impact system or other program’s performance. A program has good “runtime” and “resource usage” but it would place locks on a shared resource earlier or hold it longer than it really needs – this can impact other existing solution or potential future solution. Further runtime is not the same as “quantified performance requirement” for a solution. If a SAP solution meets quantified performance requirement, but it is running longer than it really needs, then it is not meeting “Runtime” requirement of good performance.
2.5 Go Live & Support
This is to monitor and validate application performance in production box against what is projected and address any performance concern related to the project in the production environment. As part of validation, you need to analyze production load distribution, work process usage, memory usage, workload analysis, database load analysis and cored-dump reviewed. My personal choice is to schedule SAP snap-shot program /SDF/MON to collect performance snapshot and do the review in addition to ST03, ST04 and ST22 review.
3. Further clarification
This post is based on “true” practice I adopted and executed in several major SAP implementation projects – where I was lucky to see that those projects delivered without single “true” performance issue when they went alive. For smaller/simple project, you might select what is important to you. Your company might use different term for a project phase or different phase for a SAP project, you can map those performance activities based on your situation.
Application performance control is just one area of performance control in SAP project. You can refer to my post – SAP performance control in SAP project for more in this area if you are interested.
In this post, I have mentioned performance review on technical design. I also mentioned performance training and performance testing. What should we check in a technical design review from performance point view? What are those performance guidelines/practices which a SAP developer should be aware of? How do we validate code? How should we select and define performance testing case? How do we validate performance of program via performance testing? I would try to answer those questions by sharing my experience in my future postings. Stay tuned.