Re: Is ebXML viable without basic collaborations?

[Mike Rawlins <rawlins@metronet.com>]

Todd,

People who attended the ebXML organizing meeting in December 1999 were saying
exactly the same thing, though perhaps not as eloquently or specifically.  In
addition, they were saying that we needed it in the first six months of the
work effort, not at the end.  As the work effort developed, it became
apparent that ebXML would not deliver anything as specific as you suggest,
but would focus on the technical infrastructure and analysis methodologies
that would facilitate creating what you suggest.  It would be left to other
groups to create the BP definitions and schemas.  With two months left, even
if BP and CC decided to take a drastic change in direction and try to do what
you suggest, there isn't time left to do it in ebXML.  It will need to be
done by whatever group or groups that use the work products of ebXML to
produce cross industry BP definitions and schemas.

My own 2 cents worth is that we missed the window of opportunity about nine
months ago.  That doesn't mean that our efforts will be futile, it just means
that we won't have nearly the impact that we could have.

Regards,

Todd Boyle wrote:

> 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
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org

--
Michael C. Rawlins, Rawlins EC Consulting
http://www.metronet.com/~rawlins/