Is There Li ght At The End Of The E-Mail Tunnel?

By Dave Molta  Yes, e-mail has its darker side--a side that has many knowledge workers chained to their desktops, captive to the next message that bloats their inboxes just a little bit more. It's a classic trade-off--a technology that has so many positives to offer in improving communication is also the source for horrible abuses. Imagine for a moment the effect of receiving 20 new interdepartmental memos for processing every time you step out to lunch. No thanks, I'm already full. However, network managers cannot generally ignore their responsibility to support the most functional e-mail system available. What was once primarily a decision for applicati on analysts is now much more of a strategic network infrastructure decision. And with that decision-making responsibility comes a vast amount of technical jargon related to existing and future standards. A network manager who lacks an understanding of the technical alternatives or a vision for the role of standards-compliant messaging is destined to make poor decisions. Unfortunately, technical acumen and sound vision are only part of the equation. Meeting users' needs must be a high priority as well. Consider the fact that in most organizations, the selection of an e-mail system is probably a migration, where an existing system is replaced with something newer, better and faster. And like any entrenched application, the status quo likely has the dual benefits of familiarity and stability, so this new and improved system better not fit like a square peg in a round hole. Where Are You Coming From? The installed base of e-mail environments can be classified into four categories: text-oriented host applications; shared-file LAN applications; proprietary client/server mail systems; and standards-based systems built around the widely implemented, Internet-oriented POP. Each system has its advantages, but none is well-suited as a long-term strategic messaging infrastructure. The text-oriented e-mail applications that are running on millions of mainframes and Unix servers are the oldest e-mail systems around. While early systems were quite crude, application developers have been fairly effective in overcoming the limitations of a character-based environment, resulting in easy-to-use applications that support a wide range of features. The biggest advantage of these systems is their inherent support for location-independent access to both new, unread mail and filed messages that you don't have the guts to delete. It matters little whether you're connecting to the host over a high-speed LAN or if you're dialing in from afar: The environment always looks the same. Unfortunately, with only a few exceptions, these systems integrate poorly with today's pervasive graphical desktop applications environment. Shared-file LAN e-mail apps have started fading from the landscape, but their legacy is a strong one--and more than a few organizations continue to depend on these systems daily. Using native file-system calls to access incoming and filed mail, these were the first systems to appear on LANs. User-interface qualities were very high and integration with desktop applications was great. But unlike their host-based counterparts, few were up to the challenge of accessing e-mail remotely. In addition, these systems used proprietary message transport systems, forcing you to use unreliable or unscalable gateways to send and receive Internet mail.

Other Columnists Corporate View By Robert Moskowitz On The Edge By Art Wittmann