Best Practices: Living With Applications After installation, applications still need care and feeding so they'll be able to react to other new applications and infrastructure changes (especially on the network). Moreover, network management should be proactive in capacity planning to avoid meltdowns as more applications are added to already-saturated enterprise links.

Management tools such as Compuware's EcoSCOPE and Make Systems' NetMaker/SA are evolving to support applicatio n-specific monitoring for mainstream applications (third-party tools follow market-leading applications--yet another reason to buy what sells!). Keeping an eye on actual implementations validates design assumptions across the variety of network configurations in place--conditions that can never be fully simulated in a lab. Such systems should pinpoint when applications are slower than they should be and where the problems are--such as other applications taking over the link, slower than normal frame relay and error conditions. Complex modeling and monitoring tools (even a Sniffer), however, require constant use for expertise to be developed and maintained. In addition, factor in the time for experts to be trained, hone their expertise and create baselines before problems occur.

Typical network management products initially focus on up/down problems, and, indeed, someone should know before users start calling that a network link is down. However, application-specific monitoring will show that e-mail is slo w because a queue has been stopped by a large message choking the system. Or, that a mission-critical system is slow because the server is handling large batch processes or middleware is misconfigured. Or, that new applications have been deployed without the knowledge of the networking staff. Or, even, that someone is downloading executables from the Internet.

The goal is to manage the exceptions where problems occur and to solve them as quickly as possible--to establish a baseline and then identify significant deviations from that. Better tools allow such real measurements to be used later in capacity-planning exercises.

We've seen corporations learn interesting things by tracking not just protocol traffic, but application-specific traffic loads on WAN links. One company showed me a WAN statistics pie chart, and 75 percent of the traffic was terminal emulation to the Digital Equipment All-in-One messaging host. Converting to client/server messaging might off-load a large portion of that traffic from a WAN link (though more messages with large attachments might fill it right back up again).

The monitoring tools are becoming realistic decision-support solutions for IT management. Some users are even programming performance measurement tools into applications to alert central consoles--indeed, better applications should manage themselves, at least a little bit.

We're even beginning to see products like Structured Internetworks' IPath and Packeteer's PacketShaper, which manage the bandwidth requirements on an application basis by throttling down bursty applications like Web access, file transfers, print jobs or messaging transfer activity (MTA). Sometimes, applications vendors have enabled bandwidth constrictors right into the products; Microsoft Exchange's MTAs can restrict themselves to a 56-Kbps data flow even over a T1. Sometimes prioritizing the important applications is possible even though TCP/IP and applications aren't yet quality o f service-enabled to function as predictably as SNA traffic.

Overall, a few pounds of prevention (cooperation among infrastructure and development experts, testing and monitoring) are worth tons of cure (wasted time, effort and money on less-than-successful application deployments). If organizations can establish best practices similar to those I've described, then these good habits will be well rewarded.

Bruce Robertson is a program director with the META Group's Global Networking Strategies service. He can be reached at BruceR@metagroup.com.