[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 - <turtles> 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." </turtles> 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. Cheers, -- Michael C. Rawlins, Rawlins EC Consulting www.rawlinsecconsulting.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC