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.

The Problem

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.

The Solution

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!

Advertisements

Posted by JM

Resourceful, solution-focused and intuitive reliability engineer with over 15 years of demonstrated success in architecting, developing and maintaining effective testing and monitoring solutions. Offers a wealth of knowledge and experience surrounding modern application architecture and development of best practices.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s