A network manager's life would be so much simpler if he could just tell application developers how to write those...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
pesky applications better.
You've heard this one before. The enterprise spends a ton of cash building a super-important application. But when that application rolls out on the wide area network (WAN), the network manager's phone rings off the hook. End users are having a terrible experience with the new application. It takes forever to do anything, and transactions keep timing out. The system administrators assume the network is slow or broken. The developers say the application worked just fine in the lab. After the network engineers spend two weeks trying to find the root cause, they finally discover that the developers who built the application made it too chatty to run on a WAN where users in one country are querying servers in another country. Then the finger-pointing really begins.
This scenario is fairly common because too many IT organizations remain structurally siloed despite repeated calls from industry experts for the walls that separate networking from application development to be broken down. Networking pros hear this refrain over and over again, and they nod their heads in agreement. But the question remains: How do we get these guys together when they barely speak the same language?
"Historically, it all depends on the enterprise and its culture, but some have a more traditional, siloed approach to the organization," said Gene Litt, product manager at Shunra Software, a Philadelphia-based provider of application performance testing and network emulation software. "The network engineers in the production area are fairly isolated from performance test engineers, who are fairly isolated from QA [quality assurance] engineers and developers. And you have handoffs. There are basically walls [between groups], and one group throws its deliverable over the wall to the next group in the application lifecycle."
Litt said developers usually test their applications only functionally. Then performance test lab engineers will load test the application to see how many people can use it before it breaks. However, many developers have no way of testing to see how an application will run on a WAN, where latency and packet loss can vary greatly by geography and connection quality. Litt said many labs simply test applications in a "utopian network" on the LAN.
IT organizations should break down those silos, according to Dennis Drogseth, vice president of Enterprise Management Associates. By doing so, developers and network engineers can collaborate early in the application development process. "Those companies that remain siloed are going to be on their death beds in five years," Drogseth said.
One simple step is to get everyone thinking and speaking in a common language with common metrics. Drogseth recommends that IT organizations adopt an end-user-centric measure commonly referred to as Quality of Experience (QoE). QoE is defined by individual enterprises as a multifaceted measure of the end user's experience with an application.
"Quality of experience in itself is not uniquely a networking term, and it can't be uniquely a networking term because the core idea behind it is that it's about the user experience," Drogseth said. "It can be throughput, performance and response time. It can be availability. It can be about the aesthetics of a website and the navigability needed to complete a transaction. Security can also be a factor if you're dealing with financial transactions."
Like QoE metrics, the factors that contribute to end-user experience extend across organizational silos. Those silos must be broken down so that networking pros can work with developers, system administrators and others on the development of an application.
"Networking professionals should no longer think of their responsibilities purely in terms of the network, because the network is far too instrumented and far too much a part of the delivery of a service," Drogseth said. "So the days when you can think, 'Well, I own this [network] and that's all I care about' should be gone. It's not gone in every environment, but it should be."
Drogseth said QoE is not the exclusive domain of the IT organization, either. Line-of-business organizations are also heavily involved. They are the ones that set the requirements for QoE, so IT must be prepared to collaborate with them.
In a recent survey, 79% of 207 executives and professionals from both IT and line-of-business organizations told Enterprise Management Associates that they view QoE as becoming more important to their organizations. Forty-seven percent of respondents said they already have integrated teams of IT and business people working on projects together.
"We want to break down the siloed approach of application management," said Russ Elsner, application performance management technology director at Opnet Technologies, a Bethesda, Md.-based developer of network and application performance management tools. "Traditionally, it's been the network team has network tools, the server guys have server tools, and the application guys have application tools. And the general notification that there are problems is when the user starts complaining. And then it becomes a matter of the last guy to point the finger owns the blame."
Drogseth said that the best tools within an IT organization for helping ensure QoE are owned by the networking team. "They have flow-based insights on applications," he said. "And there are a number of good tools that are sort of network-centric that are useful in capturing quality of experience."
"Another thing that's relevant from the QoE perspective is that a lot of applications are poorly designed to run on a [wide area] network," Drogseth said. "We see network managers taking a more progressive role in interacting with application development and QA to support a more proactive application design. They usually have the tools that help application developers understand that the app won't work over the network. It's usually a grassroots effort. It often starts with the network engineer saying, 'We get blamed when there's a breakage, but the breakage is coming from the development of the application. Can we do this more proactively?' "
Hans Schumacher, project manager for a business-to-business portal for a large North American manufacturer, said his team provides network emulation software from Shunra Software to diagnose application performance problems.
Schumacher's company runs dozens of applications through his business-to-business portal, used by customers, partners and employees for everything from transferring CAD files and making financial transactions to ordering spare parts and scheduling maintenance. Each application is supported by a cross-disciplinary group of developers, testers, network engineers and architects.
Schumacher's team uses Shunra's Virtual Enterprise Network Catcher to record how the company's WAN functions from link to link across the globe. Then Schumacher can distribute Shunra's network emulation software to any application group. Those groups can then simulate how an application might function during a specific transaction over the WAN.
"We put it in the hands of developers, testers, network engineers, architects," Schumacher said. "We have preconfigured a variety of geographic locations. We have set up different network conditions so that the software would emulate what it would be like for somebody in another part of the world to use an application. It helps identify any types of problems that would not be perceptible if they were just doing it over the local area network."
Schumacher hasn't yet delved too deeply into QoE for its WAN-based applications, mostly because his company has traditionally been domestically focused and applications have mostly been used in the United States. But with more international customers and offices, applications are being pushed to their limit on the WAN.
"We're trying to get people to think about [QoE] – that they are delivering applications to other parts of the world, and they need to define something that means success," Schumacher said. "But it's really up to the groups in the organization that owns that application to define what the metrics are, and a lot of times they aren't really paid for performance. They're trying to get something out the door at a lower cost."
Let us know what you think about the story; email: Shamus McGillicuddy, News Editor