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: Re: [ebxml-dev] RE: OASIS Members to Develop Universal Business Language

James Bryce Clark wrote <snipped>:

>  A few words on how repositories (and component use) may evolve.

> The run-time process user has several concerns:
>    * How well indexed and discoverable are the BPs on offer?  (Can I
>      find the LEGO piece I need?)  Is the index and taxonomy used for
>      discovery fair and neutral?  (This question is, I think, one
>      reason why the market resists proprietary business ontologies.)
>    * Are the modeled business terms fair and neutral?  Do they
>      represent a "level playing field" deal?  On whose description or
>      assessment am I relying, when I conclude that I am willing to
>      accept the business terms of the proposed collaboration?
>    * How persistent will the reference BP be?   After all, if I agree
>      to a long-running deal, the CPA I "sign" incorporates specific
>      business processes by reference or URI.   So the underlying BP on
>      which I'm relying better be stored somewhere in a stable form.
>      Who will assure me of this?  Do I have to pay someone to maintain
>      my access to a neutral reference copy, for purposes of later
>      proof or enforcement?  What if they change their prices once I'm
>      highly reliant on that access? (There's another problem with
>      proprietary ontologies.)
>    * How sure am I that the BP I plan to implement can be mapped to my
>      EAI system, or whatever else needs specifically to be
>      implemented?   Is someone selling IGs here?  What assurance do I
>      have that they will work?
>    * With how robust a set of BPs is this process related?   If I
>      automate one economic flow, I may wish to know that related and
>      cognate transactions are also modeled, or within the capabilities
>      of the underlying object model, as I expand.  (Will I be able to
>      get more LEGO pieces that fit, if I want to build a bigger castle
>      later?)

This thread has been *all* over the map, and I agree with Jamie's
earlier comment that it has been quite interesting.  In that vein, let
me offer another (perhaps tangent) observation and anecdote.  I recently
ran across the following in an article on Web Services (at
http://www.xml.com/pub/a/2001/10/03/webservices.html) :

"This attempt to define the problem at successively higher layers is
doomed to fail because it's turtles all the way up: there will always be
another layer above whatever can be described, a layer which contains
the ambiguity of two-party communication that can never be entirely
defined away."

The obscure reference to "turtles all the way up" comes from
http://www.the-funneled-web.com/Hawking.htm -


Stephen Hawking in A Brief History Of Time starts with the anecdote.

A well-known scientist (some say it was Bertrand Russell) once gave a
public lecture on astronomy. He described how the earth orbits around
the sun and how the sun, in turn, orbits around the centre of a vast
collection of stars called our galaxy.

At the end of the lecture, a little old lady at the back of the room got
up and said: "What you have told us is rubbish. The world is really a
flat plate supported on the back of a giant tortoise."

The scientist gave a superior smile before replying, "What is the
tortoise standing on?"

"You're very clever, young man, very clever," said the old lady. "But
it's turtles all the way down."


Jaime's comments on how repositories might evolve and the run-time
process user demonstrate to me that there is a risk in all of this work
of just moving the problems around (up into higher layers) instead of
actually solving them.  The hope and challenge is that as we use
automation to solve problems on one layer and move them up into a higher
non-automoted layer, that the problems we create on the higher layer
will be more tractable than they were on the lower layer when it was
*not* automated.  If we start running into more intractable problems,
it's time to back down a layer.

I observe that have been and will be considerable costs in moving the
current B2B problems up a layer or two (or more).  I also observe that
the marketplace may readily understand solving problems up a layer or
two, but beyond that there may be less perceived benefit because there
is less general understanding of the nature of the problems being
addressed.  For example, an SME readily sees the value of being able to
easily process purchase orders and send invoices.  But do they even
understand the problem of the persistence of a business process encoded
in a BPSS (that Jaime mentions above)?

I have my own opinions that I won't burden you with any further (at
least for now), but the market place will for sure let us know how far
the turtles go.

Michael C. Rawlins, Rawlins EC Consulting

[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