[ebxml-dev] Re: Addendum to Automating execution of Biz Processes ...[long]

[James Bryce Clark <jamie.clark@mmiec.com>]

At 07:37 PM 6/25/02, Andrzej Jan Taramina wrote:
> I was thinking over dinner (and
> cold Sam Adams) and wanted to add a few 
> points to my response to Mike's comments: ***

At 08:34 PM 6/25/02, Michael C. Rawlins wrote:
> *** I have spent way too much
> unpaid time on ebXML already *** when I have extended comments to make I
> prefer to post them on my web site, and not clutter up *** a list
> ***

We do talk about adoption buzz here, but no more so than on comparable
comment lists for other standards.  Mike, if you can post URLs here
for your five-part "ebXML didn't deliver what I wanted back when I
helped run it" series, we can say good things here also.

Personally I share Andrzej's (and Sam's) beliefs about how adoption is
likely to occur.  I like Mike a lot and respect his technical
opinions, but I do not agree with his monthly reminder messages of his
predictions that we will fail.  I do not think he is a troll. 
I think he is an EDI professional who is having trouble metabolizing the
ascendance of complex deployments of XML.  Which I might add
increasingly are showing up in the new releases of key EDI software
products.  Maybe even a majority of them.  It is true that a
user group for 1989 EDI translators, like the Atari users group, will
exist for a long time.  But it's not where the industry is
going.

Mike is not alone in the EDI community in fearing or sneering at web
services technology developments.   We need to win over people
with his view -- the EDI flatfile cult, so to speak -- as there are a lot
of them.   So let's reply to substantive views, not
personalities.  Mike's public statements focus on the
inaccessibility of these technologies to SMEs.   SMEs are
important.  The inclusion of their business requirements is
essential.  But they are not a likely source of early
adoption.  Which is the stage we're in.

At 02:04 PM 6/25/02, Michael C. Rawlins wrote:
> Jean-Jacques put this very
> nicely:
> > The fundamental achievement of BPSS
> > is the state synchronization between two (business) parties, ***
> While I agree with these statements, I must also note that
> they also point out one of the more formidable problems *** in supporting
> the BPSS.  Every application already has it's own state machine ***
> usually organized around *** internal business processes *** Implementing
> a BPSS will require one to map the states of these existing machines onto
> those specified *** This leads me to the conclusion that *** I see little
> utility for them in the near future *** 

Mike is absolutely right that:
  (1) EDI requires more normalization than paper.  This costs
time and money.
  (2) Synchronized states require more normalization than EDI. 
More time and money!
  (3) Within a trading community, one would need a normalized
dictionary of states to build meaningful transaction sets.  Even
more work!

However:
(1)  EDI:  It happened, in spite of the adoption costs, because
there was ROI in it for someone.   Now we are moving into a
second stage, where it is being mandated, by law (as in HIPAA in the US)
or by dominant trading partners.  There is much wailing and gnashing
of teeth about the acknowledged high costs of normalization to
HIPAA.  But there are billions of healthcare dollars to be
recovered from the efficiencies, so the benefits outweigh the complaints,
and conversion is happening.

(2)  Synchronized states:   The early ROI in synchronized
states is for big market orchestrators.  Small-volume SME trade
channels do not need normalization much.  I do not think
RosettaNet was launched by a bunch of capacitor suppliers spontaneously
saying, hey, let's spend millions of dollars defining PIPs, and
converting all our processes, so that we can all send Intel clearer
data!   Nor did hundreds of toy and apparel makers send a mob
bearing pitchforks and torches to Fayetteville, and bash down WalMart's
door with a big pole, yelling "Down with paper!  Arrr! 
Give me 850s or give me death!" 

(3) Master data dictionaries:   While I admire the visions
described by the current ebXML CC and UBL teams, personally I do
not expect the global, cross-industry normalization of data
elements to proceed quickly.  Frankly my hope is merely to
make sure that the work eventually rests with a permanent authority which
(like EDIFACT and X12 before it) has appropriate political,
vendor-neutrality and IP controls, where it will undoubtedly grind on for
a long time.  

But I do think that defined trading community subsets now have,
and will continue to create, normalized terms.  Anyone who can open
a registry can offer a data dictionary too, sufficient for a defined
subset of transactions.  To play in my sandbox, you use my
shovel.  That is how these technologies will roll out, cluster by
cluster, not by spontaneous discovery among strangers.   That
latter model is attractive -- two trading partners running towards each
other like the 1970's Clairol commercials ("the closer she gets ...
the better her business processes look!") -- but it is not where our
early pickup is happening.   

Regards Jamie

~ James Bryce Clark 
~ VP and General Counsel, McLure-Moynihan Inc.   www.mmiec.com
~ Chair, US ABA Business Law Subcommittee on Electronic Commerce 
~ www.abanet.org/buslaw/cyber/ecommerce/ecommerce.html 
~ 1 818 597 9475   jamie.clark@mmiec.com  
jbc@lawyer.com 
~ This message is neither legal advice nor a binding signature.  Ask
me why.