RE: Xtreme Ease-of-Implementation

[Cory Casanave <cory-c@dataaccess.com>]

Bob,
Thanks for starting this - I think how this is all to be used is a valuable
perspective.  I certainly agree with your perspective that this needs to be
very ease to use and almost instant to put in place. I have some different
ideas but have not figured out if they are substantially different or not.
The basic mindset difference is one of a component technology as opposed to
a "collaboration protocol package" which sounds somewhat monolithic (but may
not be).

I would hope that "packages" of this sort would not have to come from "the
big guy" but may come as off-the-shelf components in an open marketplace,
allowing "the small guy" to deal with any big guy.  This would, of course,
also allow any big guy to supply such a component suite.

Which brings me to the second part, that a "collaboration protocol package"
should not be one thing but a suite of components that address various
business and technical requirements, allowing the user to build on or
substitute components as they need to support their business processes or
integrate with their information system.  These components should follow the
business functionality "units" (E.G. Commercial transaction to collaboration
protocol) as seen in the modeling.  This should all be tied together with
high-level component tooling that allows diverse implementations of standard
protocols.

We should also seek to separate the business componentry from the technical
componentry, so that the business functionality can be used for multiple
middlewares, not just EbXml (I love it, but lets recognize the diverse
nature of the world).

This kind of component tooling and marketplace would serve the big guy and
small guy alike, invigorating the acceptance of electronic business.

Regards,
Cory

> -----Original Message-----
> From:	Bob Haugen [SMTP:linkage@interaccess.com]
> Sent:	Thursday, November 30, 2000 3:41 PM
> To:	'ebXML-BP@llists.ebxml.org'
> Subject:	Xtreme Ease-of-Implementation
> 
> One of the stated goals of ebXML is to enable smaller and less
> technically sophisticated businesses to participate in electronic
> business.  One of the hindrances to such participation in traditional
> EDI is the long time and high cost of implementation, getting up
> and running in the first place.
> 
> Here is an idea for nearly-instant implementation.  It makes 
> use of my companion "Proposal for specifying business collaborations 
> in business terms".
> 
> Here are two scenarios:
> 1. A larger and technically more-sophisticated customer wants to do
> business 
> with smaller and less-sophisticated suppliers.  
> 2. Two smaller or less-sophisticated (or smarter) companies want to do
> business together.
> 
> *First, the large-customer scenario:
> 
> The customer uses the ebXML Order-Fulfillment collaboration software 
> to package up the collaboration protocol for the suppliers.  The package 
> could take the form of a Web business service or a download or plug-in.  
> (Actually, most of what the customer needs to do will be preconfigured
> by the ebXML Common Process Catalog and my upcoming order-fulfillment 
> patterns, so their job is pretty easy too.)
> 
> All the supplier needs to conduct electronic business with the customer is
> 
> Internet access and either a browser for Web services or whatever kind of 
> computer is required to run downloaded software. 
> 
> The collaboration protocol package contains the following commercial
> transactions:
> . Order-acceptance, where the supplier receives orders from the customer
> and the 
>   package contains preconfigured acceptance documents.
> . Fulfillment-confirmation, where the package presents preconfigured
> shipping documents 
>   and the supplier can just fill in the blanks and push the Send button. 
>   (Think of it as an XML form in a self-addressed envelope.)
> . Payment protocol transactions depending on the trading partner
> agreements, e.g.:
>   . Pay on Invoice, the package configures Invoice documents for the
> supplier to 
>     send to the customer.
>   . Pay on receipt, the package receives and acknowledges Receiving Advice
> 
>     documents from the customer.
>   . Pay on consumption or production, the package receives and
> acknowledges 
>     the relevant documents from the customer.
>   . Prepayment, either directly or thru a 3rd party as in International
> orders.
> 
> The package should also contain terms and conditions and actions for all
> the
> possible things that could go wrong.
> 
> The basic idea here is that the more-sophisticated customer packages up
> both sides of the business process with its less-sophisticated suppliers
> and all the suppliers need to do is fill in the blanks in some forms and
> send them back.  The suppliers can extend the packages as much 
> as they want, e.g. connect them to their internal systems, but the basic 
> collaboration will still work correctly and new suppliers can get up
> and running very quickly.
> 
> *For small customers dealing with small suppliers, the whole 
> collaboration could be packaged up as a Common Business Process
> and used as-is.
> 
> Comments?  Suggestions? Etc?
> 
> Thanks,
> Bob Haugen