In order to help IT organizations get better at application delivery, the 2009 Application Delivery Handbook created a framework that IT organizations can customize for use in their environment. The four primary components of the framework are:
- Network and application optimization
This tip focuses on the management component of the framework.
Why is networked application performance so tricky?
Relative to network management, one of the most dramatic facts affecting the ability of IT organizations to ensure acceptable application performance is that in the vast majority of instances in which the performance of an application is beginning to degrade, that degradation is noticed first by the end users and not by the IT organization. In addition, when the end users do contact the IT organization, it is often difficult for the IT organization to determine whether indeed there is a problem or if the application is actually performing within normal bounds.
A second such dramatic fact is that in the majority of instances when the performance of an application is degrading, the assumption is made that the network is at fault. This leads to a new management metric: the "mean time to innocence" (MTTI). The MTTI is the average length of time it takes the network organization to prove that it is not the network that is causing the performance of the application to degrade. In many cases, once the network organization has proven that it is not the network that is at fault, the assumption is made that some other component of IT (e.g., the servers) must be the cause of the degradation. This defensive approach to troubleshooting tends to elongate the length of time it takes to resolve the problem.
It is not unusual for a large enterprise to have hundreds of networked applications. The business importance of these applications, however, varies widely. An IT organization will not be successful with application delivery if it attempts to focus its management attention equally on each one of these applications. For example, assume that an enterprise has 300 networked applications and that it takes a network engineer a month to get a thorough understanding of a typical application, the types of data flows it generates, and the factors that affect the performance of the application. If the IT organization attempted to get a thorough understanding of all of its 300 networked applications, it would take 25 person years of work. Even if IT organizations could afford that much of an effort, by the time they were through analyzing their applications, the characteristics of those applications would have changed to the point where the work the engineers did was of little value.
Service-level agreements for internal users
Since it is not possible to effectively manage hundreds of applications, IT organizations must use a combination of technology and their understanding of their company's business processes to identify a small set of applications that are critical to the successful execution of the company's key business processes.
Once the IT organization has identified the company's business-critical applications, the next step is to begin to craft a service-level agreement (SLA) for each of those applications. The SLA should contain a brief description of each application, some of the key features of each application, and a couple of availability and performance goals. Until a few years ago, it was virtually impossible to find an IT organization that offered such an SLA to its internal users. While it is still not common for IT organizations to offer internal SLAs, it is becoming more common.
One of the advantages of offering an internal SLA is that because it contains performance goals, it removes some of the subjectivity around whether or not the performance of an application is within acceptable bounds. There are, however, disadvantages associated with offering an internal SLA. In particular, ensuring acceptable application performance is extremely complex, in part because any component of IT (e.g., the LAN, WAN, SAN, servers, mainframes, firewall, database, etc.) could be the cause of degraded performance. In addition, the cause of the degradation could be a factor beyond the control of the IT organization, i.e., it is a third-party application and it is badly written. As such, offering an internal SLA exposes the IT organization to being evaluated based on its ability to perform tasks that are at best extremely complex and at worst impossible. To mitigate this risk, IT organizations should not publicize the existence of these application SLAs until the organization feels very comfortable that it can meet the goals specified in the SLAs.
Once the IT organization has identified the handful of critical business applications, they must also identify the key components of the IT infrastructure. The phrase "key components of the IT infrastructure" refers to the specific infrastructure components (e.g., WAN links, servers) that support the company's critical applications. These are the key components, because if one of these components is either not available or is not performing well, one or more of the company's critical business applications is likely to be affected.
The next step is for IT organizations to quantify how the performance of those key components affects the performance of the company's critical business applications. For example, assume that the IT organization has established an SLA for one of the company's critical applications and that the SLA states that the application response time will not exceed five seconds. In order to directly relate network management to the performance goals contained in the application SLA, the IT organization must understand the WAN delay's impact on application response time. Let's assume that as part of testing the application, the IT organization determines that as long as the round trip WAN delay is less than 80 ms, the application response time is acceptable. This knowledge, combined with the appropriate management tools and processes, enables the IT organization to monitor those WAN links to identify when the WAN delay is approaching 80 ms. When the round trip WAN delay is approaching 80 ms, the IT organization can then take appropriate action, such as increasing the capacity of one or more WAN links.
Dr. Jim Metzler, Principal at Ashton Metzler and Associates, is a widely recognized authority on both network technology and its business applications. In more than 28 years of professional experience, Jim has helped numerous vendors refine their product and service strategies and has helped enterprises evolve their network infrastructure. He has directed and conducted market research at a major industry analyst firm and has run a consulting organization. Jim holds a Ph.D. in Numerical Analysis from Boston University. He has co-authored a book, published by Prentice Hall, entitled "Layer 3 Switching: A Guide for IT Professionals."