Re: AW: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components ...

[David Lyon <david.lyon@globaltradedesk.com>]

Todd,

It isn't as simple as you might think and I don't believe that there is a
conspiracy
as you would have us believe.

The fact is that nobody has (yet) released a reliable business messaging
product
that is suitable for Small Business use. That is the main problem.

The Accounting Software providers know this. They can't write one either so
they
just stick with what they are good at, writing accounting systems that don't
talk
to each other.

Millions/Billions was spent on developing EDI. It's not that people haven't
tried.

The Europeans spent big on X.25/X.400/X.500 technology in an effort to get
that to work.

The Web was probably the first big jolt as the cost of networking equipment
became affordable.

Don't be fooled, the world can only move so fast. There are *real* technical
challenges involved.

One point that I would like to make is that with SBCs (Single board
computers)
it is quite feasible to put an accounting system on one of those.

With a Flash Disk RAM chip, you get 64MB which is plenty enough for a Small
businesses transactions for the year.

See http://www.embeddedx86.com/epc/ts3300-spec.php for quite a good one
and go to the local camera shop to see where they sell the Flash Memory that
you can plug in.

Consider the practical implications: A Plumber can have his ebXML server
implanted on the dash of his van. When people make a reservation, it comes
up on the screen.

Other possibilities: Video Shops, Pizza places, Small Hotels that could
never
afford a "server solution" can all use tiny SBC based connectable accounting
systems that all talk to each other.

This is the Small Enterprise vision. It's the same computer firepower that
the
big companies have, only it's running from a whole set of mobile locations.

What I would suggest is to start making something for this market. That's
how
Intuit and the others started. Now it's grown from nothing to being a ver
huge
market indeed.

Best Wishes

David Lyon
Product Manager
www.globaltradedesk.com

----- Original Message -----
From: "Todd Boyle" <tboyle@rosehill.net>
To: <rachelf@ix.netcom.com>; "'Frank. Christopher'" <C.Frank@seeburger.de>;
"'Christopher Harvey'" <ckharvey@zaratechnology.com.sg>;
<mike@rawlinsecconsulting.com>
Cc: <ebxml-dev@lists.ebxml.org>; <mblock@blocktax.com>; <doug@sleeter.com>
Sent: Wednesday, April 24, 2002 10:37 AM
Subject: RE: AW: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components
...


> At 03:17 PM 4/23/02, Rachel Foerster wrote:
> >Todd,
> >
> >Way to go. But, and this is my beef....if QuickBooks enjoys 80% market
> >share, and I believe it does, then why on earth can't one user of
QuickBooks
> >interoperate with another user of QuickBooks for the electronic exchange
of
> >purchase orders and invoices. Gads, this should be a walk in the part for
> >the developers at Intuit! And furthermore, Quicken and QuickBooks should
> >interoperate as well!!! Child's play!!!!
>
> That is the $64,000 question we have been asking for ten years,
> on the accounting newsgroups and the inescapable conclusion
> is that, whatever else a vendor might include in an accounting
> system they must NEVER provide functionality that allows users
> to easily migrate to other platforms.  Vendors who had open interfaces
> went the way of the dinosaur.  Lock-in works.  That's that.
>
> Ask yourself, why hasn't there ever been a lingua franca for data
> files between accounting systems?  Whenever somebody starts
> designing one, the vendors head the other direction, on purpose.
>
> Many in alt.accounting and the quickbooks groups also conclude,
> that Intuit does want to capture some type of portal role between
> their users and the rest of the global economy.  You can see
> that clearly in the design of Quickbooks.com website and the number
> and variety of network communications launched by Quickbooks directly
> to Intuit or to the Quickbooks portal, with or without the consent of
> users.   Clearly Intuit will not put open interfaces on the product,
> if their users are so passive that they will allow Intuit to operate
> as a portal, collecting percentages and limiting their access to
> competitive products and services.
>
> Another factor:  it is widely agreed by now, that software vendors
> should prevent any excessive accumulation of add-on or 3rd party
> markets from accumulating because that can severely limit their
> flexibility to deploy new generations of software (the legacy user-
> base problem).
>
> For example, there were so many applications on
> btrieve databases, or the novell network stack, etc. in the 1980s
> and early 1990s it was a major hassle for Microsoft until they
> gradually destroyed all those applications one by one.   Ditto
> for the browser.  If the MSIE browser were W3C standard or
> if it stood still for very long it would be imitated, and everybody
> would start writing software against the clone instead of Win32,
> or the new DotNet cr*p.
>
> Microsoft succeeds in putting together a single platform, year
> after year by skillfully dispersing any bloc of users whenever it
> gets too large, having dependencies on any API.   Intuit will have
> to do the same thing.
>
> When Intuit follows through with its promised "QBXML"
> interface and its new Intuit Developers' Network it will be setting
> the clock ticking towards one of two paths:  either a very large
> and rather rigid market with thousands of interoperating users
> depending on the 2002 versions of APIs, or, a devastating and
> wrenching changes in the APIs in 2004, 2006 etc. similar to
> what Microsoft does,
>
> Another factor against a big ISV community: whenever you have
> that pattern, competitors start cloning behavior patterns. For
> example, Intuit has something like 3000 developers @ $1000 apiece,
> registered in its developer network.  If they produce 3000 really
> great applications that use QBXML (or whatever API) then surely,
> clones of Quickbooks that cost less money, will start appearing
> to use those APIs.  In fact you will certainly be able to connect
> many of those Quickbooks addons directly to each other without
> any Quickbooks in the middle.
>
> Which brings us back to ebXML common semantics, common
> business process definitions, the RegRep etc.   I love this ebXML
> stuff, it is the best hope for all of us,
>
> Todd
>
>
>
> ----------------------------------------------------------------
> The ebxml-dev list is sponsored by OASIS.
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.ebxml.org/ob/adm.pl>
>