Core Components Methodology Draft comments

[Bill Chessman <bill.chessman@sfo.harbinger.com>]

To whom it may concern on the Core Components Project Team:

I realize it's a little late in the game for comments (but still within the
time limit), so I'd like to offer my own with regard to the latest draft of the
core components methodology document entitled, "Methodology for describing Core
Components Analysis and Proposal (Draft-Ref.04)."

I confess that my time has been filled with many work-related things, so I
haven't had a lot of time to follow the proceedings of the team, so my comments
may have already been dealt with previously.

Thus far, the document does not seem to me to be a description of a
methodology.  While it does present information on how to register pattern
definitions, etc., it doesn't discuss the heart of the matter:  How to
define/discover business components.

Additionally, I worry about the examples that are presented.  They appear to be
based entirely on the conversion of EDI data structures to like-kind
XML-friendly structures.  I thought one of the main reasons for the ebXML
initiative was to take a different approach to solving electronic
business-to-business interaction.  The problem with EDI was that it took a
largely data-centric approach which was concerned with the packaging of the
data and it's transfer from partner A to partner B (nothing else in the process
of the "business" was germaine).  Converting EDI structures to XML-friendly
structures (schemas? DTDs?) doesn't answer or help out with the business
processes.  The "new framework" is starting to look frighteningly similar to
the "old framework".

I realize that my comments are perhaps based on the document out of context
of the business modeling process, but I don't get much of a feel as to how that
process would influence this one...if at all.

I also worry about the screen shots of the registration activities.  Having
spent much of my time maintaining an internal database where we keep electronic
representations of a number of different EDI standards, I couldn't help
noticing that these screens bear a passing similarity to the tools I've
developed and used over the last five years.  This is not in any way intended
to be a claim of copyright or plagiarism...far from it indeed.  It simply
suggests that the "methodology" being represented is actually more like a
user's guide to a registration process.

Finally, I note that the document talks about "object-oriented" concepts but,
frankly, I'm not seeing all that much OO there.  Aside from the fact that there
are "objects" in the diagrams, they might as well be data structures arranged
in hierarchical patterns.

It's been my impression that, at least from the UN/EDIFACT side, the intention
was to use the work of the TMWG as a starting point for the development of the
ebXML framework (I think the groundwork was all shown in the TMWG document
known as N090).  The focus was not on document standards or semantic
repositories or specific components...it was on framework, infrastructure,
modeling and process.  If the framework and infrastructure are there, then the
users can determine the business processes and use the modeling techniques and
methodologies to develop the scenarios and, ultimately, the core components
that are useful in this brave new world.

Respectfully submitted,
Bill Chessman