Best Practices: Choosing Applications Establish a new discipline in IT and call it Infrastructure Development. Technical expertise should include good overall understanding of the impact of applications on infrastructure, particularly servers and networks. Individuals with these skills and experience should be included on application development and procurement teams. Naturally, no networker or relational database expert will actually choose an application; businesspeople will do that with the help of application development staff. But these choices should be made with all requirements considered, including server and network impact.

All too often, only after the fact do networkers hear that a mission-critical application will require TCP/IP on every desktop or massive upgrades in WAN bandwidth to succeed. Moreover, application developers often don't think about WAN issues at all, and they pr ogram only on LAN speeds, fooling them selves into thinking all is OK.

With sufficient infrastructure expertise on the application decision team, pertinent infrastructure requirements can be spelled out in advance and included in the budget. Huge budget increases won't appear until later and in someone else's fiefdom (causing more internecine fighting among IT departments). Businesspeople will then make more informed decisions on the real cost of application choices. Infrastructure people will learn the longer-term application projects for the corporation and plan accordingly and earlier in the process. Perhaps the infrastructure team can save money by being more efficient in acquiring additional bandwidth or hardware when pricing is best, or by using the time to negotiate strongly (and then install without impacting completion dates).

Best Practices: Seeing Is Believing We've noticed that theory doesn't convince people like facts can. Specifically, application developers don't listen when infrastructure people say things like "this application is not efficient." After all, they're just happy to have found something that works and makes the business unit happy. "Just fix it," they say. But throwing hardware and bandwidth at problems is neither cheap nor always effective.

We recommend letting developers see with their own eyes what existing infrastructure can do with their application dreams. Set up a test lab. Provide a suite of existing corporate applications to test across anticipated LAN and WAN subnetworks to establish a baseline for testing the impact of new applications. In particular, duplicate as many of the actual network links that are common in the corporation as possible. On frame relay, have a drop going out to the frame relay provider's network and back in--don't test with just a router-to-router connection set at the same port speed. Bring in any application Band-Aids you might want to leverage, such as Citrix Systems' WinFrame remote-control servers, and then have an open-door policy for developers to bring their ap plications to the test lab and run them through the paces.

Develop expertise in scripting tools to drive more formal testing procedures. Bring in tools like Network General's Sniffer to profile every application, middleware and protocol at the network level to better understand the real behavior of the application.

For example, you'd be amazed at the fundamental differences in network behavior for three leading packaged applications (SAP R/3, PeopleSoft and Baan). One uses efficient home-grown RPCs, another uses chatty remote-data access middleware and the third looks like X Windows traffic. Understanding the application lets infrastructure development experts better predict the effect of network bandwidth and latencies. In fact, we're starting to see network management tools add appli- cation-specific monitoring and planning modules for major applications like SAP R/3 and Lotus Notes.