[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