RSS

Performance Engineering – Why so many companies don’t get it

The following is a series of posts that I originally wrote in www.excellingit.com but the issues raised are very relevant in this context as well. If anything, the time that past since I originally wrote this only reconfirmed the following statements.

Curious to hear your feedback on the following:

Performance Engineering – Why so many companies don’t get it

Many of you may read the headline and wonder, with so much money spent on performance engineering tools and personnel, surely most companies are getting it right. Well, most companies do get some performance engineering tasks right, but anyone familiar with the industry would agree that all or part of the following happens in almost every IT organization:

Applications are slower than initially expected
This story should sound familiar to anyone who ever dealt with deploying an enterprise application. The application goes through rigorous testing, first functional and later load and stress. Baselines are generated and average response times are predicted or estimated (and sometimes guestimated), only to find out that real end users, mostly remote but sometimes even local users experience a much slower application. It is relatively easy to verify the existence of this problem in your organization, simply compare the pre deployment response time baselines with the Application Performance Monitors (APM) statistics about the user experience post deployment. You are sure to find anything from a 2X up to over a 10X difference in response times, especially in applications that are deployed globally. Another way to validate the existence of this situation is by asking the IT department to predict how an application will perform once deployed globally, 99 times out of 100 you will not find a confident answer to that question.

Return on Investment is Hard to Show
In my line of business I get to work with a variety of organizations with different attitudes towards performance. In general there is a growing understanding that improved application performance has a positive impact on the financial bottom line. As a result more and more companies invest in performance engineering processes, tools and personnel in order to get from thinking about performance to actively addressing performance requirements (reaching the goal). However, even the most sophisticated organizations where performance is treated as a product with specific goals and objectives, even those cutting edge IT departments have a hard time showing the return on investment from their performance initiatives.

Performance Engineering becomes Load Testing
Effective performance engineering is hard to achieve. A practice that meets the performance engineering goal must address application performance from end to end. Very few organizations have the tools and expertise required to gain visibility into all the factors that impact application performance. As a result many organizations tend to focus on what can be measured and predominately that means focusing on load testing. Now don’t get me wrong, assessing an application’s ability to perform under load is critical to any successful deployment, but it is certainly not enough. Focusing on load testing is analogous to looking for a lost coin under the street lamp, load testing will highlight a set of potential performance problems, but many other may lurk in the dark and may have a bigger impact on performance than anything that comes up during the load test alone.

There are many other examples of how a suboptimal performance engineering practice manifests itself, in the 2nd part of this post we
will cover the reasons why most companies have a hard time implementing an efficient performance engineering practice.

Talk to you soon…

, , , , , ,

share

Leave a Reply

Get Adobe Flash playerPlugin by wpburn.com wordpress themes