Comments on Sun Requirements

[Mike Rawlins <rawlins@metronet.com>]

My comments (MCR) on Sun's requirements.

Turochas Fuad wrote:

> Hi Mike:
>
> Some of the overdue requirements. Jon had indicated that we'll be
> submitting this requirements as well.  See that attached text file.
>
> Talk to you folks tomorrow.
>
> Regards,
> T
>
>   ------------------------------------------------------------------------
>                              ebXML Requirements
>
> <Non-Functional Requirements>
> -----------------------------
>
> - There should be a glossary defined for terms and XML tags.

MCR:  A deliverable.

>
> - A realistic timeline of deliverables and objectives.
> - Phased approach to the development effort of ebXML.
> - Define goals and principles - a guideline to developing these requirements.

MCR:  I see this as a strategy.  Do you think the high level requirements statement that Mark Crawford posted meets your need for this?

>
> - Develop programs to align all XML initiates from other standard organizations.

>
> - Develop the maintenance model for ebXML (who is responsible, how is it managed, etc.)

MCR:  Good comment.  I think we need to call this out as a specific deliverable.

>
> - Explore the concept of using ISVs, ERP vendors and Solution Integrators to develop solutions products bases on the ebXML standards

MCR:  A strategy - I'm not sure that this is appropriate for a requirement.

>
>
> <Functional Requirements>
> -------------------------
> o SME (Small Medium Enterprises)
>         - ebXML standards must be easy and inexpensive to deploy, so that SMEs
>           can participate in its B2B business model.

MCR:  Non-functional.  I have offered several comments on what constitutes "easy and inexpensive".  Please offer further details if I
haven't captured anything you had in mind.

>
>         - ebXML must not be a bottleneck for SMEs

MCR:  Agreed, but how can we state that as a specific requirement on the guidelines?

>
>
> o ebXML standards.
>         - Must be a global standard that supports the vertical and
>           horizontal industry segment.

MCR: Agreed.

>
>         - Must support multi-lingual

MCR:  Agreed - This is an issue on our issues list.

>
>         - Standards should not construed to just X12 or EDIFACT semantics.

MCR: I think we all agree on the issue of broad, inclusive semantics.  The issue seems to be in the representation of those semantics.

>
>         - There should be a common ebXML semantic; one that is used by all
>           components of the supply chain (i.e. customers, manufacturers,
>           distributors, etc.).

MCR: Same comment.

>
>         - Development of standards must include SMEs business practice/model.

MCR:  I expressed this as scalability from SMEs to large enterprises.

>
>         - Development of ebXML standards should take into account new or improved business models.

MCR:  OK, but this assumes that the ebXML standards directly correlate to business models rather than being more of a framework.  I'm
not sure that we have achieved consensus on the basic requirement.

>
>
> o Registry and Repositories.
>         - ebXML to include the Registry and Repository services and features.

MCR:  OK, but why?  I'm still looking for a concise statement of the business requirement that R&R address.

>
>         - ebXML should explore the meta-metamodel feature in a repository. Meta-metamodel is the integration point
>           across the software development life cycle. It can become the source of semantic information for use in code generation,
>           model transformation (UML to XML, X12 to XML, EDIFACT to XML) and knowledge
>           acquisition.

MCR:   Seems more to me a strategy than a requirement.

>
>
> o Security and Transfer Protocols
>         - ebXML implementations should not be limited to a set security or Transfer protocols. It should
>           be flexible to existing and future security and transport features.

MCR:   You favor flexibility in implementing security and transfer protocols.  This negatively impacts interoperability.  Considering
our progress in resolving this type of conflict, I'm not sure we want to address it in our project team, but we at least should
highlight it in the paper.

>
>
>
> o Interoperable.
>         - ebXML must accommodate the present EDI architecture and framework.

MCR:  Please be more specific about "Accomodate".  In what aspects, and to what level?

>
>         - There must be a short term and long term plan for ebXML interoperability.

MCR:  We have identified requirements for short term (6 months) and long term (18 months) deliverables.  Are you suggesting a phased
approach to achieving interoperability with other existing XML implementations?

>
>         - Explore the CommerceNet eCo spec framework and see how ebXML can leverage on its functionality and specifications.

MCR:  A strategy, not a basic requirement.

>
>         - Explore the repository meta-metamodel as the neutral language for all types of mapping (interoperable).

MCR:  A strategy, not a basic requirement.


>
>
>
> o Education and Marketing
>         - Plans for promoting and evangelizing the ebXML standards
>         - Develop classes to educate new users/companies/organizations

MCR:  Good ideas for deliverables.  Yours are the first I've seen in this area.

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