Hi there all,
I would like to offer some alternate thinking of this item by offering the
NULL and ALTERNATIVE Hypothesis.
The Null Hypothesis:
"Using the Internet to transact business documents is cheaper than using a
VAN."
Of which the Alternate Hypothesis is:
"Using a VAN is cheaper than using the Internet to transact business
documents."
Now, the discussion begins.
Assuming I already use a VAN, $200K can get me ALOT of transactions (about 6
years worth on an average 800lbs gorilla). Remember I am only looking at
the cost associated with the price of the actual transaction, not what it
costs me to build the transaction or to communicate the transaction. If I
use the Internet, I still need to build the transaction and still need to
communicate it. So the cost associated with making and communicating the
transaction will roughly be the same. IE: the software that maps the data
to a transaction and the communications links to move the data to/from
trading partners.
Now, using the Internet, I would need a dedicated communications server that
is capable of delivering the transactions reliably to my trading partners
(using whatever technology). Using a VAN, the dedicated communications
server is provided (your transaction fees). Now if I have my own
communications server, where do I host it? I need to have dual redundant
Internet connections and if my community is large, I will need a load
balance device and several servers clustered together. Where would I host
this? It would be difficult and not cost effective to do this in-house, so
I go to a hosting provider. What are the costs associated with hosting this
with a hosting provider? How do I recover my costs for hosting this
service? Do I charge my trading partners fees to connect to my newly
established service to lower my costs?
My argument here is that when an 800lb gorilla takes this in house to
provide the service, the costs associated with provision of the service
makes them become a VAN or they wear it. If they wear the costs, are those
costs higher or lower than the VAN service (that has dedicated systems that
are shared by several 800lb gorillas so each are only paying a "share" of
the service provision).
Feel free to continue the argument as I'm sure there will be many NULL
supporters and few ALTERNATIVE supporters, but what we are aiming for is to
disprove one of the Hypothesis statements.
Best Regards,
Michael Burbury
GE ecXpress
System Administration
My views are not those of the company I work for and are purely my own views
on this subject. Please do not think that because I work for a VAN, I might
be biased towards the ALTERNATE Hypothesis. I take a passive stance that
states that both Hypothesis are equal in costs and there are no savings
associated with either method.
----- Original Message -----
From: "jwells123" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 15, 2001 9:49 AM
Subject: Re: JB Hunt and EDI to XML (and more) conversion
> Question: does IPNet provide all the traditional VAN services like
> transaction control, store-and-forward/guaranteed message delivery, and
> archiving/auditing?
>
> Also, how is non-repudiation handled without the VAN?
>
> Regarding the article:
>
> "Later, smaller trading partners will be moved onto the network, though
some
> customers want to keep their EDI links in place because they don't want to
> walk away from the managed services a good VAN network can provide,
Mangold
> admitted."
>
> I can't see why companies would want to take on the role of VAN
themselves.
> If the services provided by VANs really can be done much more
inexpensively,
> I'd think the VANs themselves would be doing so to stay competitive.
>
> "Today, integrating with trading partners is a laborious process that
> requires J.B. Hunt developers to write CICS Cobol code and tap an EDI
> translator to move data out of its IBM DB2 back-end databases."
>
> And how does XML make it easier to move data out of an IBM DB2 database?
> That data isn't going to morph into XML on its own.
>
> One other thing I don't understand: why is it supposedly necessary to
> perform application-specific development every time a new trading partner
is
> added? Can't an EDI mapper just map the existing proprietary data format
to
> the EDI format used by the trading partner?
>
> Sorry if these questions are naive, I don't work in this industry but I'm
> trying to deconstruct all the "XML kills EDI" hype.
>
> Thanks!
> Jason
>
> ----- Original Message -----
> From: "Leah Closson" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, August 15, 2001 12:57 PM
> Subject: Re: JB Hunt and EDI to XML (and more) conversion
>
>
> > In a previous position (2 years ago), I had a chance to evaluate IPnet's
> > "solution" and it is, indeed, a rather slick message
> > management/communication package, very flexible and robust, I thought.
> > I didn't take a look at the translation portion, as we weren't going to
> > switch translators, but what I saw was pretty neat (although for budget
> > reasons, not purchased) and was most definitely a VAN replacement, first
> > and foremost, I'd say. It would be nice to get some solid info, because
> > I am sure the business people who read this article will now be
> > expecting even faster monkeys pulled out of ever tighter behinds ;)
> >
> > Just my 2 cents.
> >
> > Leah
>
> =======================================================================
> To contact the list owner: mailto:[EMAIL PROTECTED]
> Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
