Too many TLAs

Opinion
Jan 24, 20113 mins

Over the last few years we have written extensively about network and application optimization (NAO).  We have also written extensively about application performance management (APM).  In the next several newsletters we are going to put NAO and APM in the broader context of application lifecycle management (ALM) and discuss a relatively new discipline – Application Performance Engineering (APE).  One obvious observation is that these newsletters have way too many Three Letter Acronyms (TLA).

Over the last few years we have written extensively about network and application optimization (NAO). We have also written extensively about application performance management (APM). In the next several newsletters we are going to put NAO and APM in the broader context of application life-cycle management (ALM) and discuss a relatively new discipline – Application Performance Engineering (APE). One obvious observation is that these newsletters have way too many Three Letter Acronyms (TLA).

While there is not a single approach that applies to all organizations, the typical application life-cycle includes phases such as gather requirements; design; build, integrate and test; implement; operate; optimize. Unfortunately, in the majority of instances the entire focus of the gather requirements phase is on identifying the desired functionality that the application has to provide. This step rarely includes a focus on defining performance objectives such as the needed response time for users who access the application over a WAN. 

This creates an environment in which the application development team is left to hope that once the application is implemented that it performs in an acceptable manner. 

A similar situation exists when an IT organization decides to make a change to the infrastructure such as implementing server virtualization. In most cases, the IT organization has no knowledge of how the existing applications will perform once they are running in virtual machines. They also have no knowledge of how the performance of a given application will be impacted if the VM that is supporting the application gets moved over a WAN to a server in a different data center. 

Hence, the infrastructure organization, similar to the application development team discussed in the preceding paragraph, is left to hope that once they make whatever changes they make, that the application performance will not be significantly degraded.

Since hope is seldom an effective strategy, it is not surprising that in many cases the new applications don’t perform well and in many other cases a change to the IT infrastructure will cause application performance to significantly degrade. 

It is common for IT organizations to attempt to improve application performance by implementing NAO functionality, typically by implementing a WAN optimization controller (WOC) or an Application Delivery Controller (ADC). There is no doubt that in many instances that WOCs and ADCs provide significant value. There is also no doubt that, as will be explained in subsequent newsletters that in many other instances IT organizations would be better served if they focused on application performance as part of developing an application and as part of making any changes to the IT infrastructure.

Jim has a broad background in the IT industry. This includes serving as a software engineer, an engineering manager for high-speed data services for a major network service provider, a product manager for network hardware, a network manager at two Fortune 500 companies, and the principal of a consulting organization. In addition, Jim has created software tools for designing customer networks for a major network service provider and directed and performed market research at a major industry analyst firm. Jim’s current interests include both cloud networking and application and service delivery. Jim has a Ph.D. in Mathematics from Boston University.

More from this author