Re: [ebxml-dev] renamed thread: State Alignment

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

Thanks Karsten!  (at least someone agrees with me to some degree).

Folks, sorry for stirring up another can of worms on what I have already 
criticized as a list with too much noise to signal.

Enough already!

At 06:15 PM 6/25/02 -0400, Karsten Riemer wrote:
>I think Mike is right, there are really two levels of state alignment that
>needs to take place.  ebXML has made a great contribution to the
>partner-to-partner (a.k.a. b2b) alignment.  Internally, clearly each partner
>has its own set of state management issues. Mapping between the two may for a
>while be 'manual', but that does not detract from ebXML's accomplishments in
>partner-to-partner alignment.  (I took the liberty to rename this thread to
>more appropriately reflect its content)
>
>-karsten
>
>
> >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
> >
> >
> >----------------------------------------------------------------
> >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>
>
>
>
>----------------------------------------------------------------
>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