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

[Peter Harrison <peterha@nothingbutnet.co.nz>]

On Wednesday 24 April 2002 10:22 am, you wrote:
> Hi Bob!
>
> Your points are good ones. But the concept of seeking complexity is
> worthwhile exploring. My experience and observation in many things, and not
> just software, is that if you start out with a very simple tool without
> much complexity, make it a very useful tool that truly solves a problem,
> then over time the user who gets hooked on the very simple tool with ask
> for and use more complexity that's built on the simple tool they use and
> like.
>
> Think for a moment, about the first microwave ovens that came on the
> market....very simple: set the time and start the sucker. People got hooked
> and over time additional complexity was introduced. Now I can almost wash
> the dishes in my microwave oven, and even at that, I only use about 20% of
> its capabilities. And to use another analogy, how about the VCR....too
> complex and the users mostly do what with it? Watch prerecorded tapes with
> the time blinking 12:00!!!

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.

The hard fact is that up front design in detail doesn't work. Not only does 
it not work in practice - I can give you many examples of failed large scale 
up front design projects - but it doesn't work in theory either. I'm not 
suggesting we don't plan and design, I'm just saying that we have a unfounded 
belief that we can plan in minute detail far in advance of what is realistic.

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.

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.

There  have been some discussions about SME vs Corporates, and perhaps to 
some extent the inequality of SME vs Corporates is true. However perhaps even 
the corporates should be worried about a process where the design of a system 
is not tied to real implementations that are actually in use.

As an example of a system that does work I will refer to the JSP 
specification. The JSP system has a working open source implementation - 
Tomcat - which is the living embodiment of the written specification. Tomcat 
is also a production quality Java web server. The JSP specification is being 
evolved to meet the needs of thousands of real developers who are able to 
access the source, and have input into Java Community Process. The point here 
is that this process is evolutionary - meeting the needs of those who are 
doing JSP every day.

Currently the ebXML system is disembodied - there is nothing like Tomcat - a 
binary which you can download and start using - for ebXML. The effect of not 
having real implementations and too much detailed 'architecture' building is 
that we have a huge cathedral of a standard.

That's the point I think. I joined the ebXML group because I wanted ebXML to 
provide me with a standard I could implement. Instead it gives me solutions 
to problems I don't have, and an architecture which is grand but irrelevant 
to the needs of my customers.

I have avoided sending messages like these in the past because I know many 
intelligent and dedicated people have put so much effort into ebXML. However 
to stay slient and see something that could be so positive miss the mark 
while I stand quietly by would not do justice to the project.

My objective in these messages is to make people think about what we could do 
to address the issues, not to criticize the people who have dedicated so much 
time to this effort,

Regards,
Peter Harrison