[ebxml-dev] RE: OASIS Members to Develop Universal Business L anguage

[James Bryce Clark <jamie.clark@mmiec.com>]

A few words on how repositories (and component use) may
evolve.

Specifically, to rise the policy discussion once again - who is the likeliest operator for such repository

• Certainly there will be "open" repositories, where people are invited to contribute their Business Processes for re-use by others.  (There have been several announcements, as noted on this list.)   But this is not the only path available.
• Some repositories may be semi-proprietary.  A marketplace organizer might create a set of superior inter-operable business models, provide detailed, guaranteed implementation guides for them for an add-on price, and offer them only to subscribers.  Or they might leave the BPs openly available, and sell only the methodology that shows your 1996 Oracle ERP system how to execute them. 
• There also may be wholly private ecologies -- if the Covisint model ever takes off, for example, the auto OEMs might well create standard processes which are "offered" only to subscribers (such as qualified Tier 1 vendors) and constitute the exclusive range of terms available from those OEMs for certain defined economic arrangements.  (Sort of "my e-way or the highway.") 
• Do it yourself is also possible.  As a would-be trading partner, I can put out my "own" self-authored BPs on "my" repository and see if anyone wants to do business with me on those terms.  (C'mon down!)

The run-time process user has several concerns:

• How well indexed and discoverable are the BPs on offer?   (Can I find the LEGO piece I need?)  Is the index and taxonomy used for discovery fair and neutral?  (This question is, I think, one reason why the market resists proprietary business ontologies.) 
• Are the modeled business terms fair and neutral?  Do they represent a "level playing field" deal?  On whose description or assessment am I relying, when I conclude that I am willing to accept the business terms of the proposed collaboration?
• How persistent will the reference BP be?   After all, if I agree to a long-running deal, the CPA I "sign" incorporates specific business processes by reference or URI.   So the underlying BP on which I'm relying better be stored somewhere in a stable form.   Who will assure me of this?  Do I have to pay someone to maintain my access to a neutral reference copy, for purposes of later proof or enforcement?  What if they change their prices once I'm highly reliant on that access?  (There's another problem with proprietary ontologies.) 
• How sure am I that the BP I plan to implement can be mapped to my EAI system, or whatever else needs specifically to be implemented?   Is someone selling IGs here?  What assurance do I have that they will work?    
• With how robust a set of BPs is this process related?   If I automate one economic flow, I may wish to know that related and cognate transactions are also modeled, or within the capabilities of the underlying object model, as I expand.  (Will I be able to get more LEGO pieces that fit, if I want to build a bigger castle later?)

And, more to the point, how is the business person in your example supposed to notify the repository operators that there is a gap and (s)he has a proposal to fill it wit such and such component?

My impression is that this functionality would need to be part of the repository functionality. While it is standards bodies that maintain the official list of core components, the use of those components will be up to the business users.* * *

You could call up RosettaNet or EDIFACT's EWG today and say, "I need
a Frammistat transaction and your codes don't include it.  Please
add one."   When would they listen to
you?    It depends on whether your problem is unique or
common, whether you're within their defined scope of service, and how
inclined they are to change.   

Think instead of a library as the metaphor.  There will be competing
libraries, but not all will be comprehensive, and we will not always use
them.   If you and I do an e-deal (by signing a CPA which
references specific BPs), we may agree to string together a series
of BPs from the common library.  We may also agree to use
some processes, transactions or objects that are peculiar to the two of
us, by creating a shared definition and referencing it, and decline the
library version.   My reason may be because the library doesn't
have what I want -- or because it does, and I don't like
the terms in the library's version.  It may depend on the
availability of adequate generic versions, the peculiarities of the
specific transaction, the evenhandedness or bias of the proposed
component, the transparency of the proposed component, or our respective
market power.

Remember, what we are assembling out of these LEGO pieces is a
contract.  Your mental image should be the smiling user-car salesman
handing you a sheaf of papers:  "Here you are, it's the
standard deal;  just sign next to the twelve little yellow
tabs."   Sometimes you sign;  sometimes you read it
carefully;  sometimes you give him your own terms instead.  It
depends on who he is, what you're buying, and how much you care.

Regards   Jamie

James Bryce Clark    
VP and General Counsel, McLure-Moynihan Inc.
Chair, ABA Business Law Subcommittee on Electronic Commerce  
(www.abanet.org/buslaw/cyber/ecommerce/ecommerce.html)
1 818 597 9475   jamie.clark@mmiec.com   
jbc@lawyer.com