Re: [ebxml-dev] BPSS and WSCI

[bhaugen <linkage@interaccess.com>]

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>