>When automobiles where introduced did people stop using trains? NO!
This is a good point, Dick. Especially the train/auto example because the auto has
been around for a hundred years and the train still has good value for some purposes.
The shared model vs. in-control model is certainly a valid factor and is an excellent
point.
I would like to add some balance here (especially after some of the VAN bashing I have
seen here recently) and point out that there are some other factors: pros and cons
that have come to light in this thread. here are a few pros and cons as I see them
and how they affect us:
1. Distribution to TPs (trading partners): this is clearly a VAN "Value Added"
benefit. where one has dozens and hundreds of TPs, doing a single connection is far
easier to maintain. Doing your own transport to dozens and hundreds of sites requires
in-house support and that incurs a cost. Where the number of TPs is small (as in our
case under a half dozen), this is much less an issue.
2. Security: I am finding there can be incompatibilities between differing Internet
transport products. Also for "homegrown" Internet solutions, this requires some
knowledge and maintenance again adding to the cost. This can be another "Value Added"
in favor of the VAN and for many TPs is another reason to out-source.
3. Cost: cost accounting is no simple subject and the simplistic " X dollars per KB
on the VAN vs. zero dollars on the Internet" is really just a starting point on
computing which one is going to be financially beneficial. Points one and two above
are some of the other factors to consider in the cost issue. The VANs do things that
the TP would otherwise have to maintain adding to the cost on the other side of the
issue. Answers here are not at all clear cut.
4. The Email black hole argument: this seems to be a recurring anti-Internet
argument. I am not sure of the full validity of what I have read on both sides, but
this does not affect me so much because we won't be using an email solution. Rather
our solution will likely be a direct HTTPS or FTP connection where we know of success
or failure immediately and can take appropriate action. Again this "taking
appropriate action" requires a support infrastructure for us that is another valid
"Value Add" argument for the VAN.
5. Now we come down to the issue most important to my current project which is also
the title of this thread: "The Need for Speed" I have some update info to give that
modifies my earlier statement on our speed issues. Our VAN can route and deliver EDI
messages within seconds if the TP is on our VAN.
Yes, the TP still has to have a polling process to periodically pick up, but 1. this
can be done in very small increments as in every so many seconds and 2. as Mark
pointed out an electronic notification can be sent to trigger mail box polling to the
receiving TP. Of course on the other side: 1. requires TP change that they may not be
agreeable to and I need more data on 2. How is this notification sent? If by MIME,
then don't we have the email problem as above?
Most importantly however is the fact that different TPs use different VANs that must
interconnect. Now as a general rule our VAN connects data to the other VANs every
minute or two. This could be an acceptable speed for us except for one tiny fact.
our VAN can only guarantee us a 2 hour delivery time where an interconnect to another
VAN in involved. Obviously a VAN can guaranttee it's own services, but can't speak
for all other VANs combined.
This presents us with a huge problem. To re-iterate our needs we are building an XML
equivalent to our existing EDI with our Logistics partners to support rapid delivery
service orders to our customers that now are moving into two hour, four hour and soon
one hour delivery requirements. This is to deliver on our customer service contracts
that replace broken routers/parts. This is a very high speed need as companies rely
heavily on 24X7 internet services.
Part of that 1, 2 or 4 hours is the message delivery time. we would like to
consistently have message and functional ack complete under 30 seconds. This leaves
the max amount of time to the logistics partner to execute the delivery. An EDI
delivery system of 3 or 4 minutes might still be deemed acceptable except for one
thing. If all we can guarantee is 2 hours and 4 minutes (because of the 2 hour VAN
interconnect guarantee) then we are completely hosed! even if the delivery is still
normally 4 minutes, our service metrics are at the mercy of the 2 hour guarantee that
is outside of our control. Even though I agree there are definite "Value Added"
benefits to VANs, this one thing is a deciding factor that pushes us out of the VAN
solution for this particular high speed application.
If anyone has additional data that adds to, modifies or contradicts our view on this,
I would love to hear about it. Nothing we are doing is written in stone and we
continue to evaluate ideas and options.
Steve
Steve Bollinger 408-853-8478
Cisco Systems B2B Service Logistics Pjt
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
