[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: CSG Answers to Mark Crawford's Questions regarding the UN/CEFACT Position Statement on ebXML
The following passage appeared in a message posted a few days ago
on the uncefact-tmg-general, ebxml-dev, cefact-atg, and cefact-tbg
lists:
[Klaus-Dieter Naujok <knaujok@attglobal.net>, Mon, 27 Oct 2003:]
|
| All three BCF principals could have been easily aligned from the
| beginning of the ebXML project, which was first envisioned by
| UN/CEFACT but due to the objections by OASIS, especially Sun
| during the Tokyo ebXML meeting, we were all forced to make ebXML a
| loosely coupled set of technical specifications and remove
| business requirements modeling as an ebXML requirement. It is
| evident today that this forced ebXML to be just technical
| infrastructure.
This generated a follow-up discussion on the uncefact-tmg-general
list that included the following:
[David RR Webber <Gnosis_@compuserve.com>, Mon, 27 Oct 2003:]
|
| I must say it was not just Sun, and certainly not OASIS. This was
| voted on by the Plenary and agreed as part of the ebXML
| Requirements.
|
| The decision was to not MANDATE the use of UML/UMM, but rather to
| suggest the use of UML/UMM.
|
| There were a number of attempts made to retroactively undermine
| this decision - but each time people (not just Sun!) stood firm
| and re-endorsed the original design decision.
|
| I see it as a great strength that ebXML is neutral to modelling
| technology - thereby making it easier for people to adopt and use
| ebXML without having to use IT specific software engineering
| technology.
[Klaus-Dieter Naujok <knaujok@attglobal.net>, Mon, 27 Oct 2003:]
|
| David,
|
| I am sorry to say you don't know what you talking about since your
| were not part of the discussion. I spend (wasted) 3 days on this
| subject during the Tokyo meeting at which OASIS, represented by 3
| Sun members, made it perfectly clear that they disagreed with
| UN/CEFACT's approach and would NOT support it as part of ebXML. I
| was NOT a bad dream. If anyone is trying to adjust history it is
| those who where not present during that closed meeting of the
| executives.
[Klaus-Dieter Naujok <knaujok@attglobal.net>, Tue, 28 Oct 2003:]
|
| Due to some extended travel over the last 24 hours I was not able
| to respond to David's and Duane's postings. However, Paul and Jim
| did take care of it so that we can move on. I like to thank them
| both not only for addressing those questions/comments but also in
| confirming that my statement about the Tokyo Executive meeting
| were accurate. This last point is very important since I have been
| accused privately that my "comments are not reflective of the
| facts".
Having defamed several of us on a number of mailing lists, Klaus
now desires to "move on." Unfortunately, I feel compelled to
respond.
I say "unfortunately" because this is a level of discussion I try
assiduously to avoid, and with 30 people to host at the UBL TC
meeting in San Francisco this week, replying in this thread is the
last thing I want to be doing right now. My current job as chair
of the UBL TC, and particularly the efforts we are making to work
closely with the business experts in UN/CEFACT, puts me in an
especially difficult position from which to respond to political
attacks. But misleading statements were made about Sun's
involvement in an ebXML Executive Committee meeting that occurred
three years ago, and those statements need to be corrected. The
three people from Sun who attended the November 2000 meeting in
Tokyo referred to by Klaus -- and by Jim Clark and Paul Levine in
other messages in this thread -- were Karsten Riemer (by
invitation of the Executive Committee), myself (by invitation of
the Executive Committee), and Bill Smith, then the President of
OASIS. Karsten (lucky man!) is now retired, which leaves just
Bill and me to tell the tale. Guess who drew the short straw.
Let me start by correcting the inference that any person who
didn't know him would draw from Klaus's statement that OASIS was
"represented by 3 Sun members." The obvious implication is that
Sun had three people on the ebXML Executive Committee. That this
is the conclusion one would be led to is demonstrated by David
Webber in his postings to the uncefact-tmg-general list 27 Oct
2003, where he does in fact draw just that conclusion. Klaus,
Jim, and Paul seem happy to allow David to believe this, but I'm
not.
The fact is that the ebXML Executive Committee consisted of just
four people, two of them representing UN/CEFACT and two
representing OASIS. The UN/CEFACT representatives were Ray Walker
and Klaus-Dieter Naujok; the OASIS representatives were Bob Sutor
of IBM, Chair of the OASIS Board of Directors, and Bill Smith,
President of OASIS. Neither Bob nor Bill were participating in the EC
as vendor representatives. Rather, they were participating as elected
officers of OASIS. Both were there as representatives of the entire
OASIS membership, and both, as far as I know, were scrupulous in their
discharge of that obligation. So the mere suggestion that either of
them were pushing corporate agendas, either in the Tokyo meeting (which
Bob did not attend) or at any other time during the course of the ebXML
initiative, constitutes a completely unwarranted attack on their
integrity as individuals.
Klaus's assertion that "OASIS... made it perfectly clear that they
disagreed with UN/CEFACT's approach and would NOT support it as
part of ebXML" glosses over an essential and little-known fact
about the ebXML partnership between UN/CEFACT and OASIS that must be
taken into account in understanding what really happened.
Those of us coming from OASIS naively thought that a project
called "ebusiness XML" was going to be about ebusiness and XML.
UN/CEFACT had come to OASIS seeking help with an initiative to
drive the benefits of EDI to SMEs and countries with economies in
transition. Our understanding was that UN/CEFACT and X12 members
would provide the business expertise, and OASIS would provide the
XML expertise, and when we were done, we would have basically a
standard, cross-industry version of RosettaNet that would extend
the known benefits of EDI to small and medium-size businesses.
This was a concept that had been discussed for well over a year
prior to ebXML under the generic heading of "XML EDI," and that's
what we thought ebXML would look like -- an XML version of EDI
that would improve on 20 years of implementation experience with
standardized XML formats for the messages, standardized XML
machine-readable formats for the business process specifications
and trading partner agreements, and a standardized XML
registry/repository for registration and discovery. This is what
we signed up for.
In an internal memo dated 28 August 2000, Karsten summed up Sun's
understanding of what ebXML was doing as follows:
Main goal is to provide the process context around the messages
that EDI has always been missing. BP team is developing a
metamodel for business process definition, as well as for the
relationship of business process to business message structure,
and to trading partner agreements. This metamodel takes the
form of a UML profile. It will be possible to define processes
in UML based tools and have them translated into XML for
storage in the repository.
Business Processes will provide the contextual reference that
is needed to compose a multitude of process specific message
structures using the same pool of core components, i.e.
re-useable data elements. Trading partner agreements can be
thought of as the functional and technical agreement on what
the software on either end of the transport must be able to do
(and not do) in order for the business process to be executed
as agreed.
We will demo the relationship between business process
definition, message definition, and trading partner definition
in the Tokyo meeting.
A significant contribution has been made by University of
Michigan to incorporate an micro-economic model into the BP
metamodel, so that you can describe contract formation, and
execution against the formed contracts.
The ebXML metamodel is likely to become fully aligned with the
metamodel underneath RosettaNet, the edifecs business
collaboration metamodel. This will ensure full interoperability
between any process defined in terms of RosettaNet PIPs and
processes defined in ebXML.
The metamodel will be firmed up by the November ebXML meeting
in Tokyo, but a full, formal specification may not be available
until February meeting in Vancouver.
Given the implication in the recent tmg-general thread that Sun
was somehow pursuing a self-serving agenda here, I will point out
that Sun had zero product interest in pushing this architecture.
Like most other ebXML participants, we were just trying to deliver
the fairly straightforward return on investment people would get
by putting their paper and fax-based business processes online in
an incremental and therefore believable way. No one saw this as
the ultimate solution, just as the obvious next step, a
recognition that we should tackle first the parts that an ordinary
human being might hope to understand without having to buy into a
solution based on vendor-controlled middleware.
A similar view of the objectives of the ebXML effort at that time
was contained in the draft of the BP part of the ebXML
architecture document that was submitted to the ebXML Technical
Architecture team in early October 2000:
A business process can be seen as a series of actions on
entities within an enterprise, interleaved with a set of
communications with parties outside the enterprise. The
communication between the parties is the shared part of the
business process. This is the focus of ebXML.
The entities within an enterprise are called business entities,
and their data structure can be represented by business
objects.
The communication with parties outside the enterprise takes
place through an exchange of business messages.
Both business objects and business messages are composed from
core components, re-useable low level data structures. The
exact composition of a business object or a business message is
guided by a set of contexts derived from (among other sources)
the business process.
This was the view of ebXML shared by the majority of the ebXML
participants, as demonstrated by the fact that this is the view
that they -- through a Plenary vote -- ultimately decided to
approve. It was not until a controversy over the meaning of
"business objects" arose in late September 2000 that people from
the OASIS side began to realize that a different agenda was at
work here.
Instead of constructing the XML business documents to be exchanged
in a trading relationship based on data modeling, with the idea
that these would then be referenced by XML process specifications
based on process modeling, this alternative attempted to specify a
very non-EDI-like technology that started by capturing customer
requirements in UML use case diagrams, then identifying the
process, identifying its required data structures at a high level,
recursively defining lower and lower levels of the data
structures, and finally designing the system to use those
generated data structures.
This was an approach that might have worked if we had had no
legacy systems to deal with, were designing for one industry only,
and had an almost unlimited amount of time, but this wasn't the
environment we had been assuming. Our assumption was that we were
designing business messages to integrate today's legacy today.
When objections were made to this substitute position, the
UN/CEFACT representatives to the Executive Committee responded
that this was "the UN/CEFACT vision" and that this vision was
nonnegotiable as far as UN/CEFACT was concerned.
People tend to think I'm exaggerating when I tell them that the
"UN/CEFACT vision" was one in which the business documents
themselves were supposed to be generated directly from the process
diagrams. And indeed, for anyone familiar with either XML
document design or existing systems of electronic commerce, this
is a pretty strange vision. I might not have believed it myself
if Klaus had not sent Karsten the relevant documents and
generously copied them to me so that I would finally learn, almost
a year after the ebXML project had begun, just what he had in
mind. Since I know of no other source for "the UN/CEFACT vision,"
I've appended that message below so that anyone who's interested
can see what we were permitted to learn one month before the
November 2000 meeting in Tokyo.
I leave it to others to judge the technical merits of "the
UN/CEFACT vision" as it was explained to us in September 2000 and
will simply content myself with the observation that this was not
what we had been led to believe was our mission. At the time this
message was sent, we had to take "the UN/CEFACT vision" described
in these materials at face value as the official position of
UN/CEFACT as a whole; it was not until later, after I became aware
of the years-long struggle between UN/CEFACT TMWG and the rest of
the organization, that I came to realize that in fact "the
UN/CEFACT vision" did not, and does not, represent the majority
view even of the UN/CEFACT membership, let alone the much larger
group that had gathered to create ebXML.
When it became clear that there was a fundamental disconnect
between what we had been led to believe and what was actually
intended by the UN/CEFACT leadership (meaning the UN/CEFACT TMWG,
which had effectively taken control of the organization through
its domination of the UN/CEFACT Steering Group), various attempts
were made to find some way of proceeding that would preserve the
remarkable achievements of the ebXML effort. It had become
obvious to everyone that the "UN/CEFACT vision," or whatever it
was that the UN/CEFACT side of the Executive Committee was
driving, was in direct conflict with the work of the large number
of people engaged in the CC part of the ebXML effort. I was
willing to believe that "the UN/CEFACT vision" might someday
become a workable solution, so in a message to Klaus dated 28
October 2000, on the eve of the Tokyo meeting, I made the
following suggestion:
It's my observation that what we're seeing reflects the
existence of two groups of people with different but not
necessarily antithetical agendas. One group is focused on how
we can completely automate electronic trade; the other is
focused on how we can enable small businesses to engage in
electronic trade and how we can help businesses of all sizes
make the transition from legacy systems. I believe that both
of these agendas can be accomplished if we recognize that
complete automation is a long-term goal, whereas getting the
small businesses online and beginning the transition from
legacy systems is a short-term one. If this distinction is
observed, then I think that we can achieve consensus on the TA
spec fairly simply.
I think that the people who have a vision for the long-term
goal should describe the long-term solution in a separate white
paper. This would accomplish several objectives.
1. It would put the long-term vision firmly on record and
give everyone a chance to see where this is all heading.
2. It would make clear the requirements for the long term so
that they can be taken into account in the Phase 1
architecture.
3. It would allow the TA spec to clearly describe the
minimum, largely unautomated solution that we need to
have in place for the short term.
4. It would avoid a public collision between people who
think that the role of XML in ebXML is to transmit
objects with methods and the people who think (in line
with our official policy) that the role of XML is to
convey the information needed to effect business
transactions.
5. If done quickly and thoroughly, this separation would
allow the reduced TA spec to gain approval in Vancouver.
I don't think it's realistic to expect it to gain the
necessary level of agreement in its present form.
A messier but workable alternative strategy is the one
suggested by the QR team: hold a session of the Steering
Committee in Tokyo that will allow the QR team to explain their
objections to the current draft, and resolve those objections
on the spot.
But I think it would be easier and cleaner for you to suggest
that the controversial parts of the TA spec be moved to a
separate vision document.
We entered the Tokyo meeting with the issue unresolved.
At some point during the week in Tokyo -- I can't remember which
day now -- the ebXML Executive Committee decided to invite some
people in to discuss this issue. This was a fairly small meeting;
I remember it as including about eight or nine people, all of them
there by invitation of the EC. None of the attendees had been
invited on the basis of company affiliation. Of the people from
Sun, Bill Smith was there because he was President of OASIS;
Karsten was there because of his role in the BP team; and I was
there to represent the ebXML Advisory Board, a body created by the
EC of which I happened to be the only member. It was a good
discussion. I learned a lot, and I got to deliver the suggestion
I had earlier made in email to Klaus.
The idea of publishing "the UN/CEFACT vision" as a separate paper
was never adopted, but we left that meeting with what appeared to
be a consensus that the distinction between "short term" and "long
term" objectives might offer us a way out of the dilemma in which
we found ourselves. This was not quite the same as the
distinction between "phase 1" and "phase 2" -- people had been
using those terms for a while by that time -- but I guess it was
close enough to get us over the hump.
The thing I do remember quite clearly about the Tokyo meeting is
that the group assembled by the EC to discuss the problem had
absolutely no formal role in the process that led to the ebXML
specifications as they were finally published. I like to believe
that the discussion in Tokyo helped find a way forward, but all
the actual decisions were made by the ebXML plenary, exactly as
David Webber has said. It has been widely noted that ebXML had
literally thousands of participants. Typical meetings were
attended by upwards of two hundred people, and the majority of
them came from UN/CEFACT, X12, and other centers of business
expertise, not from OASIS. The characterization of any of the
decisions made in ebXML as driven by OASIS or by any one company
is not only inaccurate but is also disrespectful of the membership
that created the ebXML specifications.
In closing, I'd like to say how sad I am that vendor politics has
been retroactively injected into the ebXML initiative at this late date.
The ebXML initiative was remarkably free from the kind of partisan
posturing we've been seeing over the last week. Perhaps it's just
because vendor participation back then was considerably different
from what it is now, but most of us shared a common understanding
of what electronic commerce needed next, and all of us set aside
corporate agendas to pursue a goal that we believed would benefit
everyone.
The good news is that almost all the pieces of the original
majority ebXML vision -- all except Core Components -- are now in
an organization whose process encourages publicly accountable,
open consultation and discourages formation of the kind of
centralized control structures that can be hijacked by small
groups with special agendas. Fostered by a loose but effective
collegiality that builds on the modular structure of the ebXML
architecture, the OASIS ebXML Business Process TC, ebXML CPP/A TC,
ebXML Implementation TC, ebXML Messaging TC, and ebXML Registry TC
continue to evolve and strengthen the majority ebXML vision forged
by the ebXML participants themselves. In combination with related
OASIS TCs -- UBL, eGovernment, BPEL, Customer Information Quality,
and others -- ebXML is delivering on its promise to become the
sensible and vendor-neutral next step for the world's electronic
businesses, large and small.
Jon
==================================================================
Date: Thu, 28 Sep 2000 15:49:03 -0700
From: Klaus-Dieter Naujok <knaujok@pacbell.net>
Subject: Fwd: Re: Meta Model
To: Jon Bosak <bosak@boethius.eng.sun.com>
F.Y.I.
==================BEGIN FORWARDED MESSAGE==================
>From: "Klaus-Dieter Naujok" <knaujok@pacbell.net>
>To: "Karsten Riemer" <Karsten.Riemer@East.Sun.COM>
>Date: Thu, 28 Sep 2000 15:35:02 -0700
>Subject: Re: Meta Model
>
On Thu, 28 Sep 2000 17:00:29 -0400 (Eastern Daylight Time),
Karsten Riemer wrote:
>can you point me to the UN/CEFACT vision, I couldn't locate it on ebXML.org
Karsten it is not a ebXML document, but a UN/CEFACT one. If will
spare you the tasks of finding it on the UN side since it has much
more than just what we are relating to. I am sending you the
material that Ray (chair of UN/CEFACT Steering Committee - CSG) is
using as he addresses this topic related to UN/CEFACT.
UN/CEFACT's Direction Paper - Prepared by two CSG members on
request of Ray for the ebXML Executive.
ebXML BP2XML - Prepared by Ray and myself taking material from
SWIFT and GCI presentations given 2 weeks ago, as well as the TMWG
BP example.
The Road to ebXML - Background how we we got here. A revised
version from my paper I made available during the last TMWG
session. This version is from my book I am writing :-)
Let me know if you need more. BTW, my working hours are M-F,
07:00-18:00 Pacific Time in case you want to call. Next week I am
in Tokyo.
Klaus
--
Klaus-Dieter Naujok NextERA Interactive
Antioch, CA USA +1.925.759.1670
PGP Finger: 6A4B 1683 CD99 E7BE F855 CC2F 4569 6BD8 76BD 1117
===================END FORWARDED MESSAGE===================
--
Klaus-Dieter Naujok NextERA Interactive
Antioch, CA USA +1.925.759.1670
PGP Finger: 6A4B 1683 CD99 E7BE F855 CC2F 4569 6BD8 76BD 1117
UN-CEFACTs ebXML Direction.doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC