re: ebXML Organizational Requirements

[Mike Rawlins <rawlins@metronet.com>]

Mark wrote this note awhile back, and I'm just now catching up on a few things.  He
raised some very good points and questions which I think need to be addressed.

Mark CRAWFORD wrote:

> Mike,
>
>     I have reviewed the outline and have no major objections - other than I
> don't agree with dropping organizational requirements.  I think those are key to
> articulating what we expect of ebXML. We need to come to consensus on what the
> long-term strategy for ebXML as an organization should be.  We should articulate
> requisite organizational requirements to support achieving that long-term
> strategy.  We should use those organizational requirements to define what we
> believe are the functional requirements and processes of the individual work
> groups.

I think that is putting the cart before the horse a bit.   From my perspective in
software engineering and project management, you need to define first what you want
to build.  Then you figure out how you're going to build it and the appropriate
organization for building it.


> I realize the ebXML steering (or is it advisory?) committee might be
> the more appropriate body to reach consensus on the organizational issues,
> however I believe we have the charter to at least articulate what we see as the
> requirements and to provide our recommended approach. I also think our group,
> once the initial functional requirements are articulated to the larger ebXML
> body, should continue in existence to further work the organizational
> requirements in behalf of, or in conjunction with, the ebXML steering committee.

UN/CEFACT and OASIS have not yet defined what "consensus" means within the ebXML
work group.  Once that is defined, the work group should have consensus around the
requirements specification according to the definition.   I would envision the
steering committee playing an oversight and coordinating role in seeing that
requirements are met and setting overall direction (subject to consensus) on trade
offs.   Determining trade offs will be very important because I believe, like in
most efforts, we will have conflicting requirements.  We will also likely have
choices for satisfying requirements that meet some and don't meet others.   I think
the requirements work group will have an ongoing role in helping to clarify
requirements and assist in identifying conflicting requirements and trade offs, but
I still think that most of our work will be finished by mid 2000.

>
>
> The following is the beginnings of what I see as the list of major
> organizational requirements issues we need to address -
>
> What do we, as business standards consensus building experts (as opposed to
> parochial X12/CEFACT/OASIS members) believe should be the solution for the
> ever-expanding universe of stovepiped XML DTDs and schemas? How do we go about
> making that solution a reality?

It is somewhat axiomatic that a single cross-industry standard is the solution for
preventing unnecessary fragmentation and duplication within industry specific (or
other proprietary), stovepiped XML approaches.   What the standard is and
encompasses can clearly be stated in terms of functional and non-functional
requirements for an ebXML application and the supporting guidelines.  I don't see
these as organizational requirements.  On the other hand, "how we go about making
that solution a reality" is clearly organizational.

>
> What are the short and long term strategies of ebXML as an entity?
> Are we creating XML standards development and management solutions to be
> implemented by OASIS, CEFACT, or ebXML?
> If we are developing solutions to be implemented by ebXML, how is ebXML
> management to be accomplished on both the short and long terms? Funded (same
> points of reference)?
> Should an ebXML standards development process follow those of W3C? X12? CEFACT?
> ISO? Other?
> What should be the long-term relationship between ebXML and CEFACT? W3C? ANSI?
> ISO?
> What should be the long-term relationship between ebXML and OASIS? BizTalk?
> CommerceOne? RosettaNet? Other XML standards bodies?
>

These are all very good questions about organizational requirements.  I will look
forward to seeing some ideas on these topics.  I will offer some myself as I get
caught up a bit more.

> What do we define as success?  How do we achieve it?

Clearly the requirements specification needs to define deliverables.  In engineering
projects we typically have formal acceptance criteria which define success in a
separate document.  I'm not sure of an equivalent for an effort like this.  Perhaps
we need another document or a section in the Requirements Specification defining
success criteria?

>
>
> With respect to functional requirements, I believe we need to include the
> following where appropriate within your outline -
>
> Should ebXML business standards follow the structure of existing X12 transaction
> sets?  EDIFACT Message models? BizTalk Schema?  RosettaNet PIPs? Other existing
> standards?

These seem to me to fall more within the area of "interoperability with other
standards", which is more appropriately considered a non-functional requirement.
The core components group is heading toward a solution which would be syntax
neutral, meaning you could map it to existing standards.  However, the mapping and
conversion process detracts from minimizing implementation and development cost.   I
think that this question will be a difficult one for the whole work group to achieve
consensus on.  My own opinion is that an approach needs to be defined that is
loosely based on existing EDI standards, but not tied directly to either X12 or
EDIFACT.  There is too much baggage and too many unwieldy, non-intuitive
constructs.  Picking only one or the other of X12 or EDIFACT will also be
problematical for the corresponding user communities.  This neutral approach would
make it more difficult to meet the requirement of a solution in the 6 month time
frame, however.

>
> Should ebXML tags replicate, incorporate, identify, reference, or otherwise
> align with EDIFACT/X12/HL7 data element/code semantic names and syntactic
> requirements?
> Should ebXML tags replicate, incorporate, identify, reference, or otherwise
> align with those of BizTalk, RosettaNet, XML.ORG, CommerceOne, or other XML
> business standard efforts?

Same comment.

>
> How can ebXML products best coalesce the structure and content components of the
> above stated standards into a single useable XML business standard?

Same comment.

>
> What are the right design rules for XML DTD's?  Schema's?

I think this is a detailed requirement that the architecture and core components
groups can best answer.

>
> What is the impact of building ebXML business standards that use the various W3C
> technical specifications as the underlying syntax when ebXML has no control over
> those specifications?

Good question.   There is a somewhat similar situation in which the development of
UN/EDIFACT messages using the ISO 9735 syntax is handled by an MOU between UN/CEFACT
and the ISO.  Maybe we need an MOU between ebXML and W3C?

>
> What is the impact of the current immaturity of various technical specifications
> on ebXML work in the short term?  Long term?

Another good question.  You can't very well build a castle on shifting sands.  I
would favor the approach that we took in X12C, that we don't build on anything that
is not an approved standard (or recommendation in the case of W3C).  I'm sure that
there will be those who don't agree with that position, though, and think we need to
anticipate standards that are in development and do some parallel development.

>
> Should ebXML create its own XML business standards repository or use XML.ORG?
> BizTalk? Other?

I think that first we need to answer the question of what business requirements a
repository is supposed to meet, i.e., why do we need a repository?   I'm not saying
we don't, it's just that I hear a lot of different ideas for why one is needed.  I
would like get consensus on why we need a repository, then we can decide what it is
supposed to do, be, and who should own/maintain/control it.


>
> If ebXML creates an XML business standards repository, who will maintain it?
> Control access?  Create interfaces with other existing and planned repositories?

Same comment.

>
>
> Moving to a more personal perspective, my client base consists of various
> agencies within federal and state governments.  Within that client base,
> mainframe legacy systems will continue for many years, EDI use will continue for
> many years, XML implementation will be as varied as the business process and
> organizational structures involved - both within and across business unit and
> agency boundaries.  The agencies, either individually or collectively, can not
> afford to participate in every collaborative standards effort underway.  As a
> result - unless ebXML or some other universally accepted XML business standards
> development and maintenance body is successfully established - their business
> requirements will not be addressed across the full range of developing XML
> business standards.  This will lead to sub-optimizing XML use within the
> government through deployments that consist of a combination of assorted XML
> business standards and internally developed federal XML schema's and tags.

This argues very well for an organizational requirement something along the lines of
"provide an ongoing single focal point and coordinating body for development and
maintenance of XML business standards."    We might achieve this requirement by
moving part or all of the ebXML work into OASIS, UN/CEFACT, or some other bodies
after the 18 months rather than making ebXML a permanent organization.  I see it as
our job to clearly state the requirement.   Figuring out how to achieve it is a
completely different task.

Mike

--
Michael C. Rawlins, Rawlins EDI Consulting
http://www.metronet.com/~rawlins/