Three Phases to Improve Application Delivery Teams

22 November 2011 ID:G00218879
Analyst(s): Mark Fabbi, Joe Skorupa

VIEW SUMMARY

Most organizations with application performance issues haven't developed the process and organization to take advantage of application delivery technologies many already own. We outline three phases to help IT organizations improve their structure to deliver better application performance.

Overview

Many organizations continue to struggle with application delivery to ensure that the performance of applications meets the business's expectations. Improving cross-discipline skills development and changing organizational focus can significantly improve application delivery.

Key Findings

  • Application delivery and optimization solutions are underutilized and poorly understood in many IT organizations.
  • The skills required to fully utilize these solutions are broad and touch on multiple IT disciplines.

Recommendations

  • Include application performance and delivery in the initial requirements.
  • Include application, network, security, server, storage and IT ops representation in application projects.
  • Use application performance monitoring and simulation tools when you're on an application deployment team to better understand possible network and application performance constraints running across a distributed network.
  • Reward project teams, not individuals or silos, for successful application delivery to encourage cross-discipline teams to work on solving application performance issues.
  • Create a team responsible for improving application performance and availability.

What You Need to Know

Application delivery solutions are often underutilized and not well-understood in many IT organizations. We find that up to three-quarters of IT organizations that have deployed advanced application delivery controllers (ADCs) use them only for basic load balancing. When faced with performance or availability challenges, these organizations often overlook the already-deployed ADC, because it was purchased to solve basic server load balancing and is typically controlled by the network operations team. By fostering cross-discipline teams to tackle end-to-end application performance challenges and skills development of key resources, IT leaders can significantly improve the deployment and operations of many applications. We recommend a three-phase approach, starting with tactical problem solving, progressing to a project-based team approach, and, finally, to organizational upgrades as skills and processes evolve.

Analysis

As applications become increasingly centralized and abstract application development environments are further removed from what gets delivered across the network, the need for ADCs, WAN optimization controllers (WOCs) and related products and services has increased. One of the biggest problems that organizations face is organizational, and not technology-based. In most cases, the functions and benefits of ADC and WOC solutions span multiple areas within IT — e.g., application, operations, network, security, server and storage groups — that can all have their interests in these technologies. Improving the cooperation among these silos and leveraging application acceleration solutions will provide significant benefits to the organization by improving time to deploy new applications, productivity of internal users, and the user experience for business partners and customers for external-facing applications.

In many cases, there is a close correlation between speed, reliability and money (through greater productivity or increased sales and customer satisfaction). As application environments become more complex due to virtualization and software as a service (SaaS), the need for improved application delivery solutions increases.

In this research, we outline three phases we have observed as our clients' thinking and organizational structures have evolved. It is possible to implement more than one of these approaches simultaneously, and it's not required to take the levels in order. However, from our many client interactions, we find that the levels often indicate the maturity of the IT processes in this area. We also find that many more clients have implemented the tactical problem solving and project team approaches before getting to the more-strategic and long-term approach of organization change.

While these organizational efforts will clearly help focus more on application performance issues, the environment will continue to be a challenge, given the moving target of application development and delivery. Two of the technical issues with application performance management are that portions of many systems are largely invisible to performance monitoring tools, and an increasing number of application environments are using distributed and cloud-based application services as part of the application. Compounding these challenges is the increasing diversity of mobile devices, all of which have different form factors, different performance characteristics and varying sophistication in their software stacks and services.

Level 1 — Tactical Problem Solving

Organizations initially tend to go through a tactical phase when they need to troubleshoot an application performance issue. At this stage, the organization may have deployed sufficient application optimization solutions, though, in many cases, we find that, even if sufficient capabilities are included in the infrastructure, they are not being properly utilized (see "Load Balancers Are Dead: Time to Focus on Application Delivery"). This is often due to the split in functions and responsibilities among the various teams that should be involved in a complete application delivery deployment.

The first step in diagnosing the likely application performance problems, and ultimately resolving them, is to involve the appropriate teams (e.g., network, operations, software as a service [DBMS], application, server, security and, application performance monitoring) and to start thinking about the end-to-end application flows. This is critically important, as we find an increasing number of problems reside in the "white space" between IT silos, rather than within the individual IT domains. The critical issue in many cases is to understand and troubleshoot how the application (and specifically the complexity and protocol overhead) operates across a network.

To start troubleshooting the problem, it is important to think end-to-end and start fine-tuning where the primary source of the delay is occurring. Finding a baseline of expected performance under various network conditions can be a good first step. Using one of the available network simulation tools (see "Understanding WAN Simulation and Network Testing Tool Alternatives" [Note: This document has been archived; some of its content may not reflect current conditions.]) can help provide this base information. These tools provide a view of how an application performs under various network conditions and workloads. While they don't necessarily provide an accurate view of likely production results, they raise users' awareness of key attributes of distributed application deployment when used prior to deployment and can help foster cross-team discussions of possible constraints. Ultimately, baseline application performance must be measured in production environments. It's critical that this baseline be established as new applications are deployed. Another useful toolset is to look at any end-to-end application performance monitoring that might be available. These tools (see "Magic Quadrant for Application Performance Monitoring") can help provide more granularity in your analysis and correlate the behavior of various components in the end-to-end chain.

The activities of application performance monitoring and simulation are not intended to place blame (known as "blamestorming"). The intent is to start identifying potential solutions that, in many cases, may involve multiple groups to select and implement a solution properly.

In many cases, some of the necessary capabilities may already be deployed in the infrastructure, but without the required options or configurations turned on. The best example is the number of client interactions where we have seen ADCs deployed without their advanced capabilities implemented. The primary reason is that to take advantage of these features you generally need not only network expertise, but also an understanding of application deployment details and, in some cases, the specifics pertaining to an individual application. Without the participation of the application team, it is difficult or impossible to deploy the application correctly.

A useful concept to adopt in these situations isn't about who owns the problem, but who owns the solution. While this sounds trite, the first is a vertical view of the work (each specialist can drill down in his or her area), but the second view is horizontal and is about the overall issue — not just an individual's piece of it. The biggest issue is often cultural, and too much time is spent within a silo demonstrating it's "not their problem." The solution is to install a culture that focuses on application performance and delivery as a metric for all teams.

Level 2 — Project-Based Teams

The objective of the second phase is to ensure that new application deployment projects get the right level of attention and input from all appropriate parts of IT. One of the biggest issues we see in many projects is the inevitable finger-pointing that ensues when application performance doesn't meet the business owner's expectations. Application teams will point to the network organization and complain about not getting enough bandwidth, and networking teams will point back to the application team about not understanding how to write applications that, today, are typically browser-based with highly distributed client access. None of these issues is relevant to the business owner, since an application either works or it doesn't.

We have come up with a process we call the "lifeboat strategy." The analogy is that all members of a project team are in a lifeboat out at sea. If everyone rows in the same direction with a common goal, the likelihood of being saved is greatly increased. Conversely, everyone rowing in random directions means that all those on the boat will likely die a horrible death. The primary idea is that there are no individual winners or losers. Obviously, a team-based type of approach must be sponsored by a senior individual in the IT organization — typically the CIO. The involvement of the business owner or his or her representative in an IT business office is also required to provide guidance.

Once this type of approach gains traction, we see a significant improvement in collaboration among the various teams. A good client example is a test and development service set up by the networking team to enable the application teams to quickly simulate performance of their applications across various networking situations. This organization deployed one of the network simulation tools in its test and development networks.

Level 3 — Organizational Reform

In 2008, the advice we offered in "Toolkit: Your Next Key Hires Should be Application Delivery Architects and Engineers" is still true. However, this is by no means common in IT organizations. Our most-advanced enterprise clients have built up a discipline in their organizations typically by expanding the roles of existing staff or teams. The most advanced have consolidated these small teams as a key group within a changing IT organizational structure. We suggest that the best approach to organizational reform is to create a consolidated team that would sit alongside existing network, server and application operations teams and report to a senior IT leader.

One of the challenges is to find individuals with the appropriate skill set and, more importantly, retaining the people with these difficult-to-find skills, as there is a recognized shortage and many with this skill will gravitate to the vendor community. The role played by the application delivery architect demands strong people skills and broad technical skills. Some organizations will fill this post from the system integration or application deployment teams, or even the application development team. Individuals from the performance monitoring, security or even network architecture teams may also fit the requirement. Larger organizations will create the team from multiple organizations and augment it by cross-training members. In all cases, a strong application and systems orientation is essential, as is natural curiosity and a willingness to learn. These technologies are evolving rapidly, so keeping up-to-date isn't easy.

The best approach for IT organizations is to foster the growth of these skills in their existing organizations. We find that the right skills and mind-set tend to come from one of two teams. The most common is from a team responsible for application performance management. This group already has fairly detailed application knowledge, but, at the same time, appreciates some of the other elements in the end-to-end infrastructure. In numerous cases, we have seen this team drive a transition from monitoring application performance to taking responsibility for and actively attempting to improve performance. It will be the team to drive the use of performance optimization features in ADCs and WOCs, develop new systems/storage/application architectures and related activities.

A second source of skills can come from the networking organization, where an individual can become curious about the more-advanced features of an ADC or application features in a WOC and pursue more skills in this area, rather than follow the common focus by diving deep into Layer 2 and Layer 3 switching and routing certifications. Once individuals or small teams have emerged, it is critical to make them key parts of all application projects and continue to foster development.

Let's begin to recognize what we really value in IT. It's not depth (except in junior people), but breadth across multiple disciplines, coupled with depth in a primary discipline. It's difficult to train people with this knowledge, except through real-world experiences with a business context — i.e., your business and your projects. In some cases, it may take forced change in disciplines, but force the change in a related discipline with the idea of expanding knowledge and creating those linkages. The most-effective IT people always look for new things to learn, and, in many cases, the most interesting areas are in the unknown areas. Enabling this learning — even motivating it — is a critical success factor as we move toward more-complex environments that include virtualization, cloud, complex business continuity scenarios and global application performance optimization. When employees realize that their value is not only how much they know in a discipline, but also how much they understand the links among disciplines, IT as a whole will become a stronger organization and more capable of adapting to these changing environments.

Tactical Guidelines

  • IT leaders must break down silos among application, network, security, server and storage teams to provide the environment required to develop the necessary skills at the intersection of these groups.
  • IT organizations should foster skills developments around application delivery and acceleration.