[ebxml-dev] Re: Core Processes to complement Core Components?

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

At 02:28 PM 6/19/02, andrzej@chaeron.com
wrote:
> In a similar vein to Core
> Components (a very worthy effort)... I was curious as to why there does
> not seem to be a Core Processes effort underway.
> I would have thought that having standardized, searchable processes (akin
> to Rosettanet PIPs perhaps) would be a beneficial thing.  These
> processes could be references, inherited from, and/or copied and modified
> similar to Core Components. ***

Arguably that is exactly what the ebXML teams led by Nita Sharma
(catalog) and Dave Welsh (BCPMC) are doing.

However, please note that these projects can only be done correctly in
stages.  It takes more patience than some B2B pundits may
have.   Permit me to address that impatience.   To have
widely acceptable "core" processes or components, with broad
enough subscription to convert whole industries, you must --  
    FIRST scope your very broad cross-industry business
requirements.
    SECOND define a working common data structure adequate
to those requirements.
    THIRD create a working taxonomy for the objects. 
    FOURTH check them for structural vendor- and vertical-
neutrality.
    FIFTH provide a vendor-neutral and vertical-neutral
objective process, and appropriate source of decision making, for
"core"-ness and normalization.
    SIXTH apply the method and taxonomy and float a
candidate set of core objects. and object interoperability
constraints
(And then seventh, refine and repeat eternally.)  

I mention this because a few pundits are annoyed that we didn't create an
ebXML Purchase Order in mid-2000.   That is because our teams
are doing it right.  Many other efforts seem either to hit steps
1-2-6, 1-6, 2-3-6 or just 6.  Strangely, many vendor-dominated
efforts want to skip steps 4 and 5....   

Personally, I suspect that "it's normalized and core because I say
so, and vendor-neutral because my company's software is the best
stuff" will not be a satisfactory answer for broad industry user
communities.  This is why the ebXML teams and the UN's involvement
continue to be key drivers.  And it is why we are getting so many
announcements of willingness to converge with the ebXML taxonomies. 

A few seem impatient to hold a wake for ebXML, or name a successor for
it, but the adopters who count all seem to be happy to help bake the
cake, and happy to wait until it comes out of the oven.  We are
building for decades here, not for next fiscal quarter.  I am not
terribly concerned that the world is going to converge on "Purchase
Order, patented by VeriSign" between now and our next
releases.  Are you?

(Having said that, it looks like a stable end-to-end ebXML 2.0 set is
likely to be frosted, cut and ready to eat by the end of the calendar
year.  But we are not PR-mongers, nor dictators, so there is no plan
to elevate that prediction from its actual status -- a rough guess based
on current work progress -- to a press release, vaporware announcement or
venture capital pitch.  We are volunteers.   I could
easily be wrong.  It's a guess.)   

Best regards  Jamie Clark
Proud to be an ebXML contributor

~ 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 why.