[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Is ebXML viable without basic collaborations?
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
Powered by eList eXpress LLC