OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Reliance on Substitutions [long] (was) Re: Overriding TimingParameters Specified in a Business Process


At 12:37 PM 8/20/01, Arvola Chan wrote:
>Do you mean I have to first create a new business process by substituting
>parameter values for an existing business process, and then have the
>CPP/CPA refer to the new business process?
>
>I was hoping to be able to do the overriding without having to create a
>new business process. Up to now, RosettaNet's policy has been to control
>the specification of partner interface processes tightly.

FYI, I think RosettaNet's caution on this front precisely reflects real 
world user needs.  Building plans around use of overrides may not lead to 
widest adoption.

I have serious misgivings about the "substitution" or "override" 
functionality, which was rolled out only at the last minute in Vienna.  I 
was not present, having concluded (incorrectly) that the "v1.00" document 
on the table there was not subject to further substantive model 
changes.   Whatever the process, though, my concern is that this 
functionality may significantly degrade user comfort with the business 
reliability of the standard.   I suspect a significant number of potential 
adopters may ban its use, so I would be cautious about making it central to 
your plans.

Many among our optimal user base wish to rely on deterministic limitation 
of possible automated business outcomes, based on their CPA 
selection.  This end-run device undermines that goal, as the one-to-one 
relation between CPAs and BP outcomes has been made one-to-many.  So:

    Prospective Adopter's Nontechie Decisionmaker with a Frankenstein 
Complex:  You mean this thing can legally bind me, without real-time human 
supervision?
    Us:  Yes, but that's a good thing, not a bad thing.
    PANtDmWFC:  Uh-huh, theoretically.  But how do I know this thing won't 
go off the rails and commit me to billion-unit purchases by mistake, once 
you hook it up to my ERP?
    Us:  Our standard protects you by providing that you are only committed 
to transactions after you've signed up or subscribed to them, by entering 
into a specific CPA that defines them.
    PANtDmWFC:  What's a CPA?
    Us:  It is a design-time agreement that defines one or more specific 
business deals, and how success or failure works, by reference to a 
definitive specification, so you can see what your range of commitments 
might be before you "go live".  It also exclusively defines the 
communication channels between the trading partners.
    PANtDmWFC:  So if I limit the CPAs to which my black box can sign up, I 
can sleep easily, because I've constrained the world of trouble it can get 
me into?

    [a]  Us (BPSS the day before Vienna):  Yes.
    [b]  Us (after):  Well, usually, unless it specifies that it can be 
altered on the fly, in which case all bets are off, but it's much more 
flexible that way ...

My suggestion is that the second alternative answer, while technically 
equally feasible, makes the standard feel materially riskier to users.  I 
think this last minute change was incautious -- and in any case, if 'twere 
done, 'twere best done with more caution and explanation than was hustled 
through.

Now, I could be wrong.  This is merely informed speculation about who "our" 
user base is, and what it wants.  Maybe substitution will be embraced by 
users.  But note how central to RosettaNet's value proposition (among 
others) is its customer base's belief that its PIP IGs -and- textual 
summaries -and- code are highly stable and reliable coordinated sets.  The 
archetypal user likes to scope the process once, as a business matter, and 
then reuse it multiple times.

More might be said about which users, resellers and market organizers 
would, and would not, be attracted to the more flexible and less 
deterministic approach of "overrides."   Suffice to say, there are sound 
business reasons why a significant number may not.  Thus I would caution 
against heavy reliance on this function in early implementations.

This issue has not been discussed much among the former BP team, due to 
post-Vienna time and organizational pressures, so I am copying that group 
here, in case anyone wants to weigh in with their own view.

Best regards   Jamie Clark


James Bryce Clark
VP and General Counsel
McLure Moynihan Inc.
Chair, ABA Business Law Subcommittee on Electronic Commerce 
jamie.clark@mmiec.com,  jbc@lawyer.com
1 818 597 9475



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC