Avoid legacy
application headaches

Network managers play a key role in Web-enabling core business systems.

In the days of the mainframe-only IT shop, network managers and application developers didn’t have much to do with each other. All software processes ran in the data center, so the network only had to carry keystrokes and “green screen” presentation bits. If those bits could get from the glass house to the desktop terminal, everything was hunky-dory.

Then came the advent of client/server applications. Software processes taking place within users’ PCs began to interact with processes on servers. As a result, application behaviors began to impact network performance—and vice versa. That is, if the network couldn’t handle the traffic that resulted from a particular set of application behaviors at a particular time, the performance of the application suffered.

Theoretically, organizations were supposed to address this interdependency between application architecture and network utilization by opening up better working relationships between developers and communications managers. The idea was that developers would check out the networking implications of their applications before rolling them out, and that network engineers would proactively troubleshoot applications in order to provide useful feedback to developers.

This, in fact, happened at many companies. IT departments that figured out a way to get developers and networkers talking to each other were rewarded with better-performing applications and more efficient use of existing network capacity.

Many companies, however, failed to adapt to the new rules of networked computing. They struggled along by trial and error. In the end, these companies succeeded not because they eventually saw the light—but because switched 100 Mbps LANs and high-speed collapsed backbones wound up delivering enough capacity to cover up all but the most egregious application inefficiencies.

The issue of developer-networker communications has returned with a vengeance, as the Web becomes the dominant IT paradigm. Now, application performance doesn’t just depend on the health of LAN segments and private WAN links. It depends on multiple ISP backbones, ISP-to-ISP peering connections and even customers’ and partners’ last-mile remote Internet access. Companies can’t just throw more bandwidth at performance problems, because they no longer own all the networks in the end-to-end delivery chain.

To make matters even worse, the rules of application behavior have changed. In the client/server world, you could try to push logic to the PC in order to reduce the amount of back-and-forth traffic to the server. In the Web world, however, zero-client and thin-client architectures are the norm, so there is actually increased dependence on distant servers. That often results in the need to send relatively small amounts of data back and forth more frequently than under client/server. Once capacity was an issue; now latency is—especially when your servers are in New York and your user is in Stockholm.

Actually, developers who write “native” Web applications usually understand these types of networking issues quite well. The biggest problems tend to arise from the Web-enablement of legacy applications, such as ERP and other database-driven systems. Often, these problems occur because developers attempt to simply graft browser-based access onto an existing client/server system.

This can be a real mistake. First of all, in trying to make a Java-based browser interface duplicate the features of a “fat” PC client, developers can create a huge amount of IP chatter overhead back and forth between the user and the server. Again, this might not be so bad if client and server are on the same campus. Interpose enough Internet hops and handoffs, however, and you’ve got a real clunker on your hands.

Second, remote Net users don’t even always want all the features and functions that are part of the core application. They’re often most interested in quick hits of specific information—not the huge data sets that fat-client users often want to download into spreadsheets or Word documents. It’s very inefficient to Web-enable all 90 features of an application when remote and/or external users only want four or five.

Security can also be a big issue. Most legacy application developers aren’t used to thinking about the security issues that arise when, for example, an executive accesses a system from a public PC in an airport lounge. Many Web-enablement architectures cache data on the client to boost performance. That’s not a great idea if it means you’re going to end up leaving that data there once you walk away from the PC. Network managers who double as security managers need to be aware of these application design issues, too.

The bottom line is that, once again, we need to look at the relationships—or lack of them—between application developers and managers of communications infrastructure. As we take e-business technology to new levels, we are sure to encounter new devils, and those devils can only be defeated by teamwork. As the lines between network and application issues continue to become even more blurry, technologists will have to rethink the application life cycle. Networkers and developers must work together even more closely than ever, so that networking is no longer an afterthought in the development process.

Comments for publication should be sent to to liebmann@comnews.com.