Picture this. You spend a morning looking over the shoulder of an SAP user we'll call Shirley as she enters customer order information, and you watch as around 11 AM Shirley starts to fidget and finally takes a coffee break when her data input task completion times, which you are timing with a stop watch, exceed 10 seconds. After she takes her break, you head back to your cube and over the course of the afternoon and subsequent days you run synthetic tests proving that during peak network usage times SAP task completion times routinely exceed 10 seconds. You document your findings and send them to your manager and to Shirley's boss, noting that based on your observations Shirley's productivity is being hampered by poor application performance--and recommending that steps be taken to improve SAP response times during times of network stress.
You ask Shirley's boss how many orders Shirley should reasonably be able to enter per hour so you can translate that information into the application response times needed to meet that business goal. You determine that for Shirley to be fully productive, SAP task response times should consistently be 2 seconds or better. You tell your boss that to meet that business goal, he'll have to open the departmental purse strings to install a QoS solution, and you convince him to fund a QoS pilot.
You complete the pilot, measure the resulting SAP task times, and create a report showing that the pilot QoS deployment consistently reduces maximum task response times during peak hours to 5 seconds. Your boss asks you to present your findings to the budget committee, which agrees that the business benefits justify deploying the production QoS solution. Shirley and her boss are delighted, and treat you to lunch to thank you. During lunch they ask you if you could please work to get the maximum task response times down to two seconds. You then go back to the drawing board. But you are not starting all over again. In fact you have a lot of new insight on what needs to be done and how to get it accomplished.
What we've just described are APM best practices embedded in a process of continuous improvement.
The goal of APM best practices is to improve application performance, and for the best outcome these best practices cannot stand alone. Each must be embedded into a continuous improvement process that ensures that your application performance supports your business needs as shown in the figure below.
The process begins by understanding your user and application needs. Then you must measure data that reflects your understanding. The data has little value unless you report it to right people within your organization. Finally, the reports need to serve as input to link performance to key business needs. At that point, your IT and business groups engage in dialogue that improves your IT group's understanding of what is important and how to measure against the new objectives--and at that point another cycle starts.
Dialogue is vital because the business group injects a contextual understanding about what really matters for applications users, and that understanding enables you to measure the right things and set thresholds that will help you optimize performance where it counts most.