Turn the Ship around; From Firefighting to Performance Driven
Jumping from one performance hotspot to the next can be very frustrating because there is never enough time to eliminate the issues. Successful companies addressed those troubles years ago. If you are still in the firefighting mode; don’t worry, I will give you insights to this dilemma and also a resolution for this frustrating development.
Slow loading or pure performing business applications are a nightmare. The longer this slowdown continues, the higher the pressure from your customers. They expect a quick bugfix and do not understand why their IT department is not able to provide a better service quality. Endless war room sessions, try end error experiments and regularly detailed status reports make those exercises even more annoying.
Traditional software development initiatives often neglect non-functional aspects. Your business clearly describes their functional demands. Software designer and developer construct the required software. Testing specialists capture those requirements with sufficient test cases. After deployment on production, the response time sucks and your business application is almost unusable during peak hours.
It takes ages for your support teams to become aware of those slowdowns. Their log file based monitoring approach does not deliver the necessary insight. System resource utilization is below the agreed boundaries. Your infrastructure teams recommend solving this issue with a ramp up in hardware. Several days later your user community is nevertheless frustrated because the performance is still unacceptable.
This performance disaster mentioned above is no one-way road. You can always turn the ship around by integrating performance considerations in your development chain. Obviously, organizations struggling with frustrated users due to slow responding applications need to understand their gaps which hold them back.
Based on my experience from hundreds of performance engineering projects non-functional requirements are essential and should never treat as an afterthought. Once you’ve documented the required aspects, your developers can consider those in their implementation decisions and your test teams can organize the required test scenarios.
Finally, you should monitor all transactions from the end user perspective. There are powerful application and user experience monitoring solutions out there which will give you the essential insights. Also, those tools come out with analytics features and enable your support teams to triage complex performance issues.
The easiest way to turn the ship around is to assess your performance engineering maturity and improve it step by step according to my maturity model.
Keep doing the good work!