This is the tenth and last newsletter in a series of newsletters that has been discussing a seldom-mentioned IT discipline – Application Performance Engineering (APE). In this newsletter we will discuss the role of APE once an application has gone into production.
This is the 10th and last newsletter in a series of newsletters that has been discussing a seldom-mentioned IT discipline – Application Performance Engineering (APE). In this newsletter we will discuss the role of APE once an application has gone into production.
Through most of this series we stressed the role of APE during the design and development stages of the application life cycle. We did that because we believe that the best approach to ensuring acceptable application performance is to build the application from scratch to be highly performant. We believe that this approach is preferable to trying to tweak the application once it is in production or implementing WAN optimization controllers just to make up for a badly written application.
However, once an application is placed into production it typically runs for years. During that time, most IT organizations will make hundreds, if not thousands of changes to the IT infrastructure. We are not suggesting that IT organizations should perform the kind of testing and analysis that we have discussed previously in this series each time the IT organization is planning to make a change to the infrastructure. The vast majority of these changes are somewhat trivial in terms of the likely impact that they will have on application performance.
However, IT organizations that are implementing major projects typically include in the project plan an identification of how they will mitigate the risk associated with the project. What we are suggesting is that for the handful of high-visibility, broad based projects that IT organizations occasionally implement that they should include in their risk mitigation plans for the identification of how the project will impact the performance of the small number of applications that the company uses to run the business.
A good example of the type of project we are talking about is desktop virtualization. As we have discussed in previous newsletters, there are two fundamental ways that desktop virtualization can be implemented – server side and client side. In some cases the IT organization will end up implementing one form of desktop virtualization for some workers and the other form of desktop virtualization for the remaining workers. Independent of how it is implemented, once an IT organization implements desktop virtualization the WAN will impact desktop performance in ways that it never did before. The bottom line is that implementing projects such as desktop virtualization without testing to determine if the implementation will result in acceptable performance creates a level of risk that IT organizations should avoid.
