Re: [ebxml-dev] BPSS and WSCI

["Michael C. Rawlins" <mike@rawlinsecconsulting.com>]

Bob,

Thanks for your observations, but I think you missed my point.  I am *not* 
"confusing the states of an external business deal with the internal states 
of the private internal business apps."  That is precisely my point.  They 
*aren't* the same. However, if you're going to execute the BPSS you have to 
track it's states, and the only place you can really go for the states by 
trying to correlate them with the states available in the application.

Furthermore, when the BPSS and BP worksheet examples have things like:

"Constraints - The invoice shall only be sent after confirmed 
shipment.  The invoice shall reflect the confirmed shipment."
"Guard Condition - ThreeWayMatach(Invoice).State=VALID"
"Preconditions - Valid Sales Order, Valid Vendor Relation"

You're telling me that you aren't expecting a BPSS-enabled application  to 
pay attention to this type of stuff?  If they are supposed to, where are 
the standard semantics for any of these values?  If we're not expecting the 
application to pay attention to them, what's the point of forcing them into 
a machine-processable XML document?

Cheers,

Mike


At 04:14 PM 6/25/02 -0500, bhaugen wrote:
>Mr. Rawlins and all,
>
>I think you are confusing the states of an external
>business deal with the internal states of the private
>internal business apps.
>
>They are not the same.
>
>The business states that need to be synchronized
>must be simple and agreed-upon by both trading
>partners in a business transaction.
>
>They only refer to the milestones in a deal where
>the parties would shake hands and say "I agree"
>if they were sitting across a table.
>
>For example, in an offer-acceptance transaction
>(such as a purchase order), the end states that
>are interesting might include whether the offer
>was accepted or rejected.
>
>These agreements on the state of the deal
>happen one way or another in trad EDI, too.
>Just slightly differently.
>
>There is a lot of confused discussion in many
>circles right now about Web "transactions".
>Most of the confusion comes from thinking
>of them as database or internal workflow
>transactions.  They get much easier if
>you think of them as normal external
>business deal handshakes.
>
>-Bob Haugen
>
>----- Original Message -----
>From: Michael C. Rawlins <mike@rawlinsecconsulting.com>
>To: Jean-Jacques Dubray <jjd@eigner.com>; 'Assaf Arkin'
><arkin@intalio.com>; <ebxml-dev@lists.ebxml.org>
>Cc: 'Ismael Ghalimi' <ghalimi@intalio.com>
>Sent: Tuesday, June 25, 2002 4:04 PM
>Subject: RE: [ebxml-dev] BPSS and WSCI
>
>
> > Jean-Jacques put this very nicely:
> >
> > At 04:07 AM 6/25/02 -0400, Jean-Jacques Dubray wrote:
> >
> > ><JJ> The fundamental achievement of BPSS is the state synchronization
> > >between two (business) parties, whether this is part of a
>"commitment"
> > >or a more casual message interchange. In any B2B message exchange
>(even
> > >between a travel agent and an airline) this is mandatory. Imagine the
> > >cost of getting periodically out of synch with your business
>partners?
> > >
> >
> > While I agree with these statements, I must also note that they also
>point
> > out one of the more formidable problems that application vendors will
>have
> > in supporting the BPSS.  Every application already has it's own state
> > machine.  These state machines are usually organized around the point
>of
> > view of internal business processes (for example, many systems won't
>let
> > you invoice without an order, or invoice without first indating that
>the
> > ordered goods have been shipped).   Implementing a BPSS will require
>one to
> > map the states of these existing machines onto those specified in the
> > BPSS.  So, added to the burden of mapping application data to UIDs (or
>EDI
> > data elements in our current world), vendors and/or end users have to
>map
> > application states to BPSS process states.  That's fine so long as the
>BPSS
> > states are uniform (like a defined dictionary of states), but if they
>are
> > different then life gets very complicated (much more so than just
> > supporting both X12 and EDIFACT invoices).  In addition, if the BPSS
> > specifies a state that can't be easily matched to an internal
>application
> > state, then either application modifications are required in order to
> > support the state or the user is forced to intervene and handle that
>state
> > "out-of-band" as a manual exception.
> >
> > And about getting "out of synch" with your business partners - I'm
>sure
> > that there are a few people who have this problem and for them I'm
>sure
> > that it is a big problem.  However, most application systems I've
>worked
> > with that support e-Business in any serious fashion are already
>configured
> > to avoid this type of thing.  I don't see it as a major concern for
>most users.
> >
> > This leads me to the conclusion that while the BPSS and the UMM upon
>which
> > it is based may be valuable tools for documenting and agreeing on
>business
> > processes (for those who find ROI in using them), I see little utility
>for
> > them in the near future for actually automating the execution of
>business
> > processes.
> >
> > Mike (OK - so I still see the glass half empty ;^) )
> >
> >
> > >Michael C. Rawlins, Rawlins EC Consulting
> >
> > www.rawlinsecconsulting.com
> >
> >
> > ----------------------------------------------------------------
> > The ebxml-dev list is sponsored by OASIS.
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.ebxml.org/ob/adm.pl>

---------------------------------------------------------------
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com