As noted in the last newsletter, the Mean Time to Repair (MTTR) of application performance issues can be quite lengthy. One of the factors is that the issues are often improperly diagnosed. In particular, in many IT organizations, when an application is performing badly the general assumption is that the WAN is the cause. However, our research indicates that in only a minority of cases is the WAN at fault.
As noted in the last newsletter, the Mean Time to Repair (MTTR) of application performance issues can be quite lengthy. One of the factors is that the issues are often improperly diagnosed. In particular, in many IT organizations, if an application is performing badly the general assumption is that the WAN is the cause. However, our research indicates that in only a minority of cases is the WAN at fault.
We discussed this issue with a network engineer for a financial services organization. He stated that in his last company, 90% of issues were originally identified as being network problems even though the reality was that only 10% of issues were network related. He pointed out that such false assumptions increase the amount of time it takes to accurately diagnose the problem. He recommended that when a problem is called into the help desk the caller should be encouraged to describe the symptoms of the problem in detail, and not just what they think the source of the problem is.
In a previous newsletter we discussed some of the reasons why traditional fault management was easier than application management and used the example of a defective interface on a router. Sticking with that example, another one of the reasons why fault management is easier than application management is because once it is determined that a given interface on a router is defective, the remedy is obvious – replace the interface.
Once the source of the application degradation has been identified, the solution is not necessarily quite so obvious. For example, consider the situation in which the IT organization has determined that the source of the application performance issue is the application itself. In particular, the application was written in such a way that it performs badly over the WAN. If the application was developed internally, then perhaps some future revision of the software will run better over the WAN. While the same could be said for software that is acquired externally, it is highly likely that the IT organization that is trying to make the application run better has little influence over an outside supplier. In that case the IT organization is stuck with trying to implement a workaround and hoping that it will eliminate most if not all of the application degradation.
We will come back to the topic of the MTTR application performance in future newsletters.