Here is the detailed answer from Mike Rawlins. It appears the previous
and current focus have remained similar if not the same. I'll make the
change proposed by Dale Moberg and send to this group by tomorrow. I'd
appreciate any comments. I am uncertain what any submission will do to
put smooth edges to this analysis. If you would like to respond
directly to Mike Rawlins, please feel free to do so.
Thanks.
==========
rawlins: Monica,
I'm not copying the list because I don't subscribe to it, but feel free
to forward this message to that list or anyone else you feel is
appropriate.
In addition to what I said in my call for participation, I also request
that submissions be original content first developed for this
retrospective. I will not categorically reject previously published
pieces, but have a strong desire to avoid them and will not commit to
using them.
I think the most helpful way to respond to your request is to outline
what I plan to do in my own retrospective. I've not written it yet, and
don't intend to until I see the other submissions. However, the main
points I intend to make are that the ebXML technical infrastructure thus
far has failed in the marketplace, and has less chance of future success
than it did five years ago, but is not dead yet. In my original series
I talked about a "son of ebXML", and it is here now as XML Web
Services. In terms of the other ebXML work areas, inter-enterprise
business process modeling a la UMM continues to be a hard sell. The one
piece of work which looks as if it may have a future is Core
Components. These are my working hypotheses, and I will offer evidence
to support them.
What I'm most interested in, and what I think will be most interesting
to readers, is evidence to the contrary. Sufficient evidence will
change my assessment. The most compelling evidence will be case studies
or reports of the use of the ebXML technical infrastructure (or even BP
modeling) in large scale, mission critical applications. Reports of or
commitment to planned implementations will be less compelling, followed
by vendor support and further development of the specifications.
Aside from that, the overall goal is to give readers a well grounded
understanding of where ebXML is now, five years after the completion of
the initial project. The scope is limited to what was covered in those
original specifications and papers. People can certainly address other
work that is derived from or based on ebXML 1.0, but ebXML should be the
primary focus.
Finally, the spirit of submissions should be consistent with my original
"Critical Analysis". People read what they will and none of us, writers
or readers, can completely escape our own subjectivity. But, I'm
looking for unbiased, objective analysis that is consistent with
"critical" as "exercising or involving careful judgment or judicious
evaluation" (http://www.m-w.com/dictionary/critical).
I hope this provides you sufficient general guidance. I've answered
your specific questions in-line below.
Monica J Martin wrote:
> Mike
> We've developed an overview summary to provide you for your request to
> do an updated assessment on ebXML. Most of the ebxml-jc have
> questions. Your feedback will assist us in providing the information
> you seek. This information I don't believe was found in the original
> email. So, if you could provide further details, it would be greatly
> appreciated. Questions are:
>
> * Adoption, usage and scope of ebXML seem important here. What is
> your intended scope and what are your goals with this update?
See above.
> * If we work with one of the previous premises [1] - this framework
> failed and this is to be a critical assessment, will solutions to
> gaps you identify be part of this update?
I don't know yet whether or not my piece will identify the gaps (at
least beyond the gaps I identified in my original series). I may change
my mind, but at this point I don't intend to address solutions to the
gaps. If submitters wish to do so they may. However, if the focus of a
submission strays too far away from the base ebXML work I won't use it.
(For example, I won't use a paper on how the W3C's XML Protocol work
fixes deficiencies in ebXML messaging.)
> * Will you include what has changed since the original piece? Has
> your focus changed in how this article will be presented?
I will address in varying degrees of detail the continued development of
the specifications, organizational changes, industry and macroeconomic
factors, and implementations. I intend to keep the focus consistent
with the laboring series.
> * (one specific from this group) In general, how is X12 CICA now
> looking to take advantage of any work in the ebXML realm (which
> includes use of emerging technologies)? How is X12 aligning with
> the UN/CEFACT work - particularly on CCTS?
An interesting question, but the retrospective is about ebXML, not X12.
Answering it adequately requires a level of detailed discussion that
would be out of my intended scope. I suppose I shouldn't find it odd
that you ask this question in relation to the retrospective, but I do.
Because of that, I feel compelled to make clear what I hope should be
obvious, that I'm wearing my "Rawlins EC Consulting" hat in this
retrospective and not my "X12" hat.
At any rate, I currently plan to address X12's CICA work in relation to
the CCTS in a separate, unrelated article. FYI, I've invited Mark
Crawford to assist me with that article and I hope that he does.
>
> Any other details relevant to any submission would be great. This will
> assist us in refining or changing what you have so the information
> will be beneficial to your current focus. Thanks.
>
> [1] Correct me here as I don't believe I was involved.
---------------------------------------------------------------
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com
