From the Network World Archive

Put more 'ability' into your E-mail RFP
By Joel Snyder

06/03/96
     You're ready to whip up a request for proposals (RFP) for an 
enterprise electronic mail backbone.
     About all you hear is that Microsoft Corp. is pushing Exchange as a 
viable option and Lotus Development Corp. is repositioning Notes as a 
corporate mail standard, and how these actions have forced vendors of 
traditional backbone
E-mail into a fight to justify their existence.
     Each of these vendors is pitching its technical implementation as the 
one that will best suit your needs.
     You listen because you know the stakes are considerable. A typical 
backbone, designed to link existing heterogeneous corporate E-mail systems 
along with Internet and X.400 mail, starts at around $20,000 but can jump 
to $100,000 in a flash. An Exchange backbone, in contrast, fits nicely into 
a $10,000 budget. 
     To simplify your selection process, try mapping out your needs along 
the lines of product ability - scalability, reliability, flexibility and 
manageability - and include those requirements  with the RFP. This way, you 
can find out which vendor can really meet your specific needs and whether 
Exchange is the right choice for your E-mail backbone.
     Here's what to consider as you scrutinize each ability:
     S c a l a b i l i t y 
     Figure out how big your backbone has to be by estimating the total 
volume of messages that will move over it. Then make sure the products you 
have in mind will leave room for expansion. Don't assume that only 
cross-platform mail - such as sending from cc:Mail to the Internet - will 
move through the backbone. Instead, count every single message currently 
moving through your E-mail systems, no matter the source or destination: 
You never know when a message may cross that backbone or if you'll need to 
have them all cross it.
     Once you have an estimated size, you can get an accurate price quote 
for hardware, software and integration services. Find out how far you can 
push that hardware and software before an upgrade is required. You'll also 
find out how many systems your backbone will need, which will help you 
project system and network management workload.
     Although some sizing problems can be solved by throwing a bigger CPU 
at the backbone, there are breaking points such as size or geography that 
will dictate when to move to a multiple-system approach. Just remember that 
a two-CPU backbone is more than twice as difficult to manage as a 
single-CPU one because you have to coordinate two systems configurations to 
maintain relatively tight synchronization.
     R e l i a b i l i t y
     Decide now just how mission critical your E-mail is. If your business 
will grind to a halt if E-mail does not flow, make this clear to vendors 
and budget for support costs accordingly. For truly nonstop service, you 
may have to double your hardware and software costs by running redundant 
servers.
     This is one area where Exchange will struggle to catch up, at least 
for a few years. With only a few weeks of production operations under its 
belt and virtually no experience in troubleshooting the most complex of 
problems, Microsoft does not yet have a reputation for E-mail experience.
     Fortunately, most E-mail backbone problems are very source-specific 
and don't affect the entire network. Beware, though, of high-end limits 
that any backbone may have, whether it be the total number or size of 
messages, the number of simultaneous connections, or memory and disk 
consumption rates. 
     F l e x i b i l i t y
     The major differences in E-mail backbones are the various messaging 
systems they connect and how much manipulation each message can receive as 
it moves along. So list the messaging systems you care about up front. 
Often, the lack of a direct link from backbone to LAN or legacy E-mail 
systems means you'll be passing through a dysfunctional Simple Mail 
Transfer Protocol or X.400 gateway with low throughput or a propensity to 
mangle attachments and addresses.
     Think hard about all of the features your backbone will need. Should 
the backbone rewrite addresses in mail headers? Do you want it to 
automatically encrypt and decrypt mail to particular trading partners? Can 
the backbone be part of your security system and work with your firewalls?
     Centralized naming and directory synchronization are very popular 
backbone features, and these are by far the hardest to implement. Again, 
vendors may claim compatibility when what they really offer is a poor kind 
of coexistence.
     For large directories or those encompassing multiple heterogeneous 
E-mail systems, insist on a thorough and technical explanation of what the 
backbone can and cannot do. If you do use centralized naming, your backbone 
should be able to use the Lightweight Directory Access Protocol (LDAP) to 
connect and synchronize with a corporate directory, such as one that uses 
X.500.
     The best approach to determining how much flexibility will suffice is 
to list the top 10 services and features you need. Then, make sure that 
each backbone you're considering has every one of them and that they are 
well implemented. 
     M a n a g e a b i l i t y
     Monitoring, controlling and logging E-mail as it passes over the 
backbone are more crucial the larger your network gets. The more mail 
passing through a system, the greater the need to have a large number of 
buttons, knobs, dials and controls for managing it.
     If your company does business with the government or you work in 
government, your backbone should be able to 'snapshot' all messages 
passing through it, even if you are not currently required to do so.
     Some high-end E-mail backbones come with graphical user 
interface-based management systems. These are nice, but make sure there's 
substance underneath the flash. You should be able to see what mail is 
moving through the backbone, turn it on or off, and get an alarm when mail 
is backing up.
     The bottom line here is that you really need to think about exactly 
what you want and make those requirements clear in the RFP. In your 
analysis of these RFPs, insist on detailed technical information, 
demonstrations and conversations with managers at sites similar to yours.
     Snyder is a senior partner at Opus One in Tucson, Ariz. He can be 
reached at jms@opus1.com.

Copyright 1995-1997 Network World, Inc.