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.