Mark wrote:
>Well, in fact, I do have
quantifiable examples to illustrate my point. You see we also utilize and
provide turnkey FTP packages that handle multiple FTP session and sends of
EDI and >other EC data. And indeed, in instances where a user needs to
communicate with several trading partners, at several different host
addresses, the log on process alone (given the >variety of the quality of
the servers hosting the FTP service) can take up to 100 times as long as a
simple deposit of a file containing several hundred ISAs in a secure
Internet based >VAN. Now, from there, it's up to the quality of the VAN
to assure instantaneous delivery. Those that are posting simple FTP servers
(like what you're proposing large EDI/XML users >do) are unable to
provide instantaneous deliver because they require intermediate processing
to take place which grabs and feeds data to interpretors. A higher quality
IVAN >centralizes the process, so deposits are in effect, posts to the
trading partners mailbox. Also, a "fly by night" IVAN might simply
let the data sit there until the trading partner picks it >up. A quality
IVAN will send electronic notification to the trading partners systems,
which can be utilized as an instantaneous trigger to run a batch process to
retrieve that data. These >are things that traditional telephony based
VANs can do without tremendous costs. Again, as our customers say:
"Don't throw out the baby with the bath
water."
Based
on the description above I counted at least two logins per interchange,
one by the "sender" into your VAN to send data, the second by the
"intended recipient" into your VAN to retrieve data. How
can two separate logins be faster than a single login by the
sender into the intended recipients own system?
Because like a traditional VAN, users communicate with several
hundred trading partners with one log-in to their secure mailbox. They can
even download one file containing EC messages for several hundred, even
thousands of trading partners.
In your
scenario, I'm assuming the "intended recipient" uses
a polling process to check for new messages at your
In fact, no. We send an electronic
notification to them once data is posted to them. They use that to
trigger queries.
VAN, this
polling interval ALONE could be longer than the time it would
take a sender to login and send data directly to the intended recipient.
Your conclusion that a VAN provides faster delivery than a direct connection
are not backed by the evidence you present Indeed, they are. There is another assumption in your
assertions, in order to receive your supposed efficiency all parties
MUST BE ON THE SAME VAN, what about the overhead and cost incurred when
multiple VAN's are involved in an interchange? We
inter-connect.
>Still, in order to experience reliable,
secure and timely transmissions, the receiver must have, at minimum, an FTP
server on stand-by, waiting to receive your
>transmission. You must also have
something to manage the outbound and inbound
traffic.
I never said anything about
FTP, I always recommend HTTP because of it's ability to handle both
bulk file exchanges and interactive web forms. The software that's
needed to manage inbound/outbound Internet EDI is relatively low cost,
compared to many companies VAN charges.
>And so what you
propose is that high volume trading partners interact directly, and low
volume users utilize intermmediary VANs to gonglomerate data. That's
interesting because our
> high volume clients say "For the
price, I'd rather pick it up all in one place, not have to maintain a system
for managing traffic myself, not have to higher people to maintain it and
not
> make my trading partners worry about
several different methods of security, transmissions and
communications." But you have a valid point here. Perhaps there are
users at some > level (approximately $1000 a month user
(approximately 2.5 MB worth of EDI)) who could post an FTP server for about
$400 dollars a month and save money. Oh wait! I'm wrong. 2.5
> MB of EDI only
costs less than $200 bucks on our VAN!
That same 2.5 MB could be sent over the Internet,
directly, for $0 incremental cost
Plus the cost of
managing and maintain the systems to do this.... provided a company
has an Internet connection, most already do. Also, you're not counting
the "FULL COST" to exchange the 2.5 MB of EDI data, both the
sender and receiver are charged $200, the real cost to exchange this
data is $400 ($200x2).
Again, I never suggested using FTP, that was an
assumption on your part - MY suggestion is to use HTTP/Web technology
for both bulk EDI and Interactive Web Form based
E-Commerce.
All this discussion about cost and efficiency is
interesting but candidly another major advantage
for companies that establish their own E-Commerce capability is
"CONTROL OVER THEIR DESTINY". These companies are free to
implement advanced, unique E-Commerce applications without having to
"negotiate" with a VAN over pricing and functionality.
VAN's will continue to service companies that
believe E-Commerce is not strategic or cannot "cost justify"
implementing their own E-Commerce solution.
I'm becoming concerned that this thread may not be
of interest to the entire xmledi list, perhaps we should take this
discussion off list.
Feel free to email me privately. You
have my address.
Regards,
Mark Malatak
Dick Brooks
Dick
Brooks
