Network Computingwww.networkcomputing.com

It's been hard to observe the market and read the literature surrounding electronic commerce and directory services without recalling the conditions that surrounded NOS file servers and terminal emulation 10 years ago. New applications like e-commerce and directory services are more complicated than the NOS and, as such, will have a greater impact on us. The question is, who exactly is working on the implementation of e-commerce and directory services? That answer is hugely important because if we don't pay attention to how these network applications are implemented, we'll spend a lot of time cleaning up after ourselves in the years ahead.

At the core of the problem lies the decision-making process within our organizations and the roles networking p rofessionals play. Networking engineers have a history of limiting their involvement in broadly based IT purchasing decisions. The practice of dividing mind share along plumbing versus application lines is ludicrous (at least from a cross-discipline approach) because in the end, it just adds up to an increased workload for the already overworked networking professional. After all, who has been supporting--and will be expected to continue supporting--the mix of protocols out there? You. And who will support the applications going into beta today? You. Network engineers are drafted into supporting every possible technology, be it messaging, file servers, security packages or Web servers (and the list goes on and on).

The difference between progress and stagnation, productivity and wasted time is the ability to make an efficient, timely decision. The Internet and TCP/IP are both essentially the same today as they were in 1987, yet collectively we burned more time and money on historical accidents like IPX, Ap pleTalk, NetBIOS and NetBEUI than it would take to finance the national debt. Our industry goes off on these costly tangents because the professionals who are most capable of designing the future have punted on that opportunity. With DHCP, Microsoft overcame IP's so-called complexity in a heartbeat once it realized that until it embraced IP, Microsoft would never unseat Novell.

If you asked the average network guru for the strategic, architectural framework for networks in 1985, you would have heard TCP/IP and the Internet. But if you asked about file services and print services, you would have heard "that's an application problem." It took 10 years for the resulting chaos of protocols and products to sort out, primarily waiting for the user community to mature.

Network engineers get satisfaction from concentrating on lower-level protocols and components. It's not like we don't have plenty of work to do designing and deploying the backbone networks on which our organizations depend. Who has time to dea l with the application space? It's hard to object to the division of labor: Ten years ago we had to come up with a standard way to run Ethernet over twisted-pair, and today we struggle with ATM versus Gigabit Ethernet. See, back then no one had time to deal with file sharing, and today no one's got time for e-commerce. Furthermore, the Internet is becoming more complicated. Ten years ago you could spend a week at Interop and get a handle on it. Today, it would take you years.

But, in the end, it's just too easy to rationalize away the task of the application stack and concentrate on the plumbing. The problem is, you're forfeiting the game. After all, today's game is about applications, not protocols. As for protocols, the battle of the wire is done and IP has won. The homogeneity of a desktop and server IP infrastructure lets the world at large concentrate on new applications that were impossible in the past. But all that's about to change, because the network is fast becoming a collection of commercial se rvices or applications more than it is a collection of specifications and protocols.