-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>>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.
Well, now, wait a second... You could also look at this as a black
and white television set versus a color tv... Or 8-track versus
CD... Or, well you get the picture. The point is: VAN service as it
exsists with EDI is old technology. To survive, VAN's will need to
introduce services that work with XML and do so in a cost effecient
manner that companies can justify over the use of so called
"in-house" solutions. I don't see VAN's becoming extinct, because
they have the technical knowledge to evolve beyound the capabilities
of the average business (were not talking about Cisco Systems, Growth
Technologies, IBM, or anybody in that league... They will always be
better off doing business beyond the limitations of a VAN).
- --Brian Curtis
- -----Original Message-----
From: Steve Bollinger [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 26, 2000 2:38 PM
To: [EMAIL PROTECTED]
Subject: RE: The need for speed: XML vs. Internet EDI
>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
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOX+KUydXKV6T/lvVEQJ9zgCfXrNdXZsdI02VuhEAo1pbPswnCbIAoPs+
swZIPxnEHM2TnpKh6hzeoYcS
=fOYn
-----END PGP SIGNATURE-----
------ 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
