Is ebXML viable without basic collaborations?

[Todd Boyle <tboyle@rosehill.net>]

I am concerned that the incomplete spec of BP SS and the lack of 
convergence in the protocol stack, may effectively makes BP unusable
for small business.  Do you mind, a little reasoning on this?

Small business is interested in ebXML for reliable messaging, for 
the convergence in business vocabulary, and for collaboration
framework.

However, it is my belief that without collaboration patterns, 
ebXML may not deliver sufficient economic benefits, widely 
enough, to achieve critical mass in smaller companies. Desktop 
software isn't that bad.  SMEs needs incremental benefits of 
initial adoption.  Those benefits must be large in order to 
offset the disruption of starting up ebXML alongside their 
existing software.  You have to deliver a benefit, to the very 
first adopters.

Proprietary solutions, competing with ebXML, are emerging on the 
internet.  SMEs have a large variety of choices in payments, platforms,
 midrange software etc-- UDDI and WSDL will spawn even further 
diversity.  But without a BP specification to anchor it, to tie 
together the content of the messages, the whole mess will not be 
efficient.  It will be a frustrating, expensive, irritating mess. 

I am most afraid the independent web services and BSPs will not be 
able to serve SME subscribers cheaply, without some BP framework
to help guide the dealings for the SMEs with 3rd parties.  They
will have to hardcode their choreographies with each other, then,
they won't want to change them.

I am afraid SMEs will not get a convenient, efficient solution 
without going inside the single-vendor monolithic solutions from 
Microsoft/bCentral/GreatPlains, Netledger, or Intuit/QBweb. 

ebXML is very VERY close to making an historic contribution, to change 
this picture.  ebXML can spark a native, decentralized adoption 
*outside* the traditional organizing forces of dominant software vendors, 
or dominant purchasing agents in industry.  But timing is becoming
critical.

SMEs need a fairly small number of collaboration patterns, having 
relatively simple discrete steps, simple variables, and simple business 
documents and CCs.  

A collection of patterns for Offer/Acceptance, PaymentInstruction/
RemittanceAdvice, Order/Fulfilment for goods or services, prepaid or 
onCredit, etc.

These are essential to enable small accounting systems to "manage" all 
this crap over the internet.  We need the business layer *most 
critically*.  It is not optional. We need it even more than Transport.

We need to associate the multiple messages and transactions of each 
deal, within our systems.  We need the exception handling.  We need 
the framework for legal enforceability.  We need the semaphores that 
tell us when we have a deal --the economic event recogition. And 
most of all, the BP semantics must be ubiquitous, widely understood.

Principles to consider: 

1. Transaction patterns for SMEs are not that complicated.
2. You don't need to over-engineer it. SMEs are going to watch
    it like a hawk anyway, manually.
3. SMEs do not critically need backward compatibility. 

EbXML should not wait for any complete, enterprise blueprint before
releasing something usable for SMEs.  You can fix your mistakes later. 
SMEs are fairly tolerant of things that don't work perfectly, as
long as they are seeing progress.  As long as they see taillights
of early adopters ahead of them, running successfully.

I hope for an early release of ebXML that has baseline 
collaboration patterns for SMEs,

TOdd