RE: ebXML will end up being too expensive for small business

["Todd Boyle" <tboyle@rosehill.net>]

Wes Rishel:
> It should be noted that Mr. Boyle's signature file is associated
> with some proprietary approach to using XML for small business accounting

Whoops. Minor blooper there Wes :-)  I'm blissfully independent (which
doesn't
make me any smarter, or less biased, unfortunately)  I'm biased against
lock-in
and exploitation of small business by telcos, software cos, banks, CPAs,
etc.....
http://www.deja.com/dnquery.xp?QRY=todd+boyle+lock-in&ST=MS&svcclass=dnold&D
BS=2

SMEs need to send and receive orders, invoices and payments over the
internet.
Competition between small BSPs and webledgers are the key for this. (There
is a
list of competing webledgers on my links page.)  Web ledgers will make
obsolete
the bank, the postoffice, and most of the bookkeeping, tax prep. and
accounting
software industry.  Payments will settle inside the host for free, as
intercompany
transactions just like we've seen in large multicompany accounting systems
for
40 years.  Ask any accountant.  500,000 accountants already know how this
works.

This is much more revolutionary than "digital cash".  Digital cash sounds
revolutionary but doesn't provide a business infrastructure.  Webledgers run
the whole business process and the payments/settlements outside the banking
system.

It will be a great challenge, to create an architecture that enables
geodesic models of commerce, without biases toward hub-and-spoke
models of commerce.  I'm not talking about TCP protocols vs. multicast,
and I'm not talking about whether ebXML provides for commerce without
a registry or repository.   I'm talking about business models and
business process.

Hub-and-spoke models are prone to runaway aggregation and concentration.
Hub-and-spoke results in rent collecting based on fees, and restricted
access to competitive products and services in underlying markets.

I am far more optimistic than most of the accounting and SME communities,
at this point, that ebXML will enable SMEs to conduct business on a level
playing field with the Aribas and CommerceOnes of the world.

If ebXML is usable for webledger developers and the whole competitive
BSP industry on the internet, then SMEs will be able to conduct business
directly with each other.  The pattern at this time is free or nearly
free services, and open-ended competition because of the existence of
platforms like http://xml.apache.org/, http://java.apache.org/ ,
http://www.php.net/ etc.   The fact that we conduct business on web
ledgers is not hub-and-spoke any more than the fact that our packets
travel thru a hub at MAE West.

However, I am concerned that ebXML will be too complex, and like EDI will
have the end result that SMEs can't use it.  XML Schema are a perfect
example of this.  Nobody can write the parsers.  Its too complex.
Big software companies will decide in smoke-filled rooms, the question
if, and when, and how, XML Schemas will be implemented.

There are similar influences on the ebXML spec:

 - anything that makes the architecture complicated, will reduce the
number of vendors who can build the "ebXML transport server" or the
"ebXML Registry/Repository server" or its endlessly fascinating little
mechanisms.  Already we have people making a living, designing ebXML.

 - complexity creates little pockets and gardens and niches where other
cognitive mindplays can develop, which help these complex areas grow
deeper.  The industry will instinctively gather anyplace where the sun
doesn't shine, and the DNA will organize itself around its food source.

 - the big win for XML server vendors, EAI vendors and MOM/MQ vendors
is something that checkmates the user into needing a commercial server.
The most likely place for this to happen is always in the security,
reliability, and authentication area.  Watch out for an ebXML that is
real good and reliable, but only if you either

 * use a billion-dollar Hub like Ariba, who handles the complexity, or
 * buy an expensive XML server, MOM, MQ server etc.

 - if they can't get the big win, simply breaking ebXML is good enough
for many of the established middleware, EDI, and other companies.  It
is my belief that delaying ebXML or burdening it with troublesome
and complex glitches will give them optimal economic outcomes.  This
comment is based upon observations of the present customers, products,
and economic roles and the revenue streams of these companies and is
not directed at any specific company.

Please realize the telcos and other infrastructure industry does NOT
want SMEs to have any decent network unless we pay business class fares,
over $100/month.  They have worked pretty hard since 1993 to make sure we
never get low-latency, jitter-free connections; otherwise we'd all be
talking long distance over the internet by now.  Similarly, telcos and
cable companies work very hard to lock-in their subscribers, prevent
e-commerce servers on the DSL connections and cable modems, and ensure
Top-Down selling.

My two cents is that you're building a software solution to work
around what are really intentionally-engineered limitations, in todays
IPV4, jittery, unreliable, multipath, high-latency, insecure, unregulated,
telco-controlled internet.

Don't we need some element of political diplomacy, or other strategy that
bells the cat?  We need a 9th ebXML Project Team, to form a delegation
and talk to these internet infrastructure providers about minimal
QOS for ecommerce.  We should say "EBXML Requires Port A,B,C, etc and
latency below 50ms and blah blah as an absolute condition" and that
ebXML transport negotiation requires a test of those conditions to
setup a connection.  IOW its an up-or-down decision.  If you're an ISP,
you cannot sell ecommerce without meeting those QOS's.

The telcos and ciscos of this world have studied this chessboard 6, 7
moves ahead.  Here's an example.  They all agreed on a completely multi-
vendor "neutral standard" for IP telephony called H.323.  But you can't
use it unless you open fifteen ports plus UDP.  It's near impossible
to run a firewall that handles H.323, and it requires fifty round-trips
to setup a call, and the UDP isn't routable.  We were checkmated, years
before we even knew what the issues were.  To this day there's no
telephony over the internet.

ebXML has no more power than anybody else, if you accept the IPV4
unregulated, insecure internet.  You are almost predestined to a two-tier
ebXML that gives the best quality and the lowest costs, to big
corporations and sticks the retail user and SME with high costs.

ebXML is fond of stating, "EbXML will be transported by every reasonable
transport including SMTP, HTTP, etc"   This sounds democratic, but
contra-intuitively, what this really means is there will be business-class
transport options that cost a lot of money, and economy class which
is unreliable, your purchase order gets lost, etc. etc.

ebXML should consider transporting EVERYTHING over a single protocol
(such as an extended version of HTTP, Instant Messaging, etc.)
which EVERYBODY has access to, to prevent a two-tier solution which
would result in benign neglect of the SME.  I don't know.  Just an
idea.  Forget about the SMTP, store-and-forward, etc. models.  Just
let service providers sell various gateways for lower-grade service.

I apologize for yet another, long-winded essay on Small/midsized
business issues.  Maybe all these things are under control.  I have
great respect for ebXML list.  We have some first-class chessplayers
of our own here, working for the interests of SMEs.






=======================================================================
= This is ebXML, the general mailing list for the ebXML committee     =
= The owner of this list is owner-ebxml@oasis-open.org                =
=                                                                     =
= To unsubscribe, send mail to majordomo@lists.oasis-open.org with    =
= the following in the body of the message:                           =
=      unsubscribe ebxml                                              =
= If you are subscribed using a different email address, put the      =
= address you subscribed with at the end of the line; e.g.            =
=      unsubscribe ebxml myname@company.com                           =
=======================================================================