[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