OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

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!

(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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC