Re: AW: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components ...

[bhaugen <linkage@interaccess.com>]

Peter and all,

I'm going to cut your well-written argument into
snippets with embedded responses.  I hope
I do not distort your argument, because I am
sympathetic to parts of it.

From: Peter Harrison
> Has anyone here looked at Extreme Programming and its principles.
> Extreme Programming (XP) is all about letting go of our tradition of 
> up front design and instead working on an evolutionary way.

I love XP and wish that ebXML had done a lot more
test-driven evolutionary code development.  However,
XP came along in parallel to ebXML and so I have
no idea whether it would have been practical.
Certainly it would not have fit the culture.

At the same time, there have been lots of software
vendors, both big and small, who have been 
implementing parts of ebXML in parallel with
the design efforts.  There have even been
a few open-source projects.

The feedback loops have not been as tight
as XP would have made them.  Plus the
"voice of the customer" has not been 
at all unified.  See also below.

> The problem as I see it with large complex systems 
> and specifications is that without being evolved and 
> implemented in the real world from their inception
> they have not been tested against the fitness function 
> of the real world. We have no real way to know whether 
> what we are doing fits the needs of real
> people and businesses.

You might not know this, but most of ebXML was
pretty directly evolved from previously existing systems
by people with rich experience in those existing systems.
It wasn't all that divorced from the real world.

Core components were designed by people with many
years of practical experience in traditional EDI.

The context ideas may be a new invention, but they
came from sad experience with EDI variations and
implementation guides.

BPSS was mostly based on the design of RosettaNet.
In fact, RosettaNet has said they may may use BPSS.

CPA was mostly based on IBM's tpaML, which had been
around since at least 1997.  (That's the stuff IBM
claims to have a patent on, (for which they also said
they won't charge royalties).)

> I have found it very hard understanding ebXML because 
> it is solving problems I - and a huge majority of my customers - 
> simply don't have. It is not solving the very few problems that 
> my customers do have. In other words, the
> promise of "electronic business XML" is not being fulfilled -
> essentially because the process is all design up front.

I don't know what problems your customers have that
are not being solved, and I'm not disputing your
disappointment.  But I don't know if XP would have helped.
(In other words, I suspect your diagnosis is a little off.)

We have a project in eBTWG called Business Collaboration
Patterns that starts with real-world business problems.
So far they have all come from big companies or industry
associations and have all used existing EDI documents.

So if those are not your customers (e.g. if your customers'
problems include wanting newly-designed and standardized
XML documents) then you might still be disappointed
if ebXML had all been XP.  XP really depends on the voice
of the customer(s), and if the only customers who have
time to participate are big companies, then the priorities
get skewed that way.

I wish I had a good solution for this set of problems.
I've been discussing them with some XP experts,
but the problem of SME customer involvement is
tricky.

-Bob Haugen