Re: ebXML metamodel write-up

[Duane Nickull <duane@xmlglobal.com>]

Peter:

This is not quite what we were talking about (although I totally agree
with what you were saying).  The dependency is between the data element
layer and the business process layer.  Think of business processes as
verbs and data elements as nouns.
The dependency arises from the issuance of a statement of business
requirements to a trading partners.  For instance, I - as Trading
Partners #1, place an edict on my website (perhaps in an eco.xml format)
stating that I require a confirmation for each purchase order I place
and that I do not consider the PO placed until such time as I receive
confirmation.   That is a business method but it is dependent on the
data element layer (noun) because I also have to specify what I need in
that confirmation.  I may require the name, address, original PO number
and total price in the confirmation.  Those are all data elements (core
components perhaps?).  Without being able to specify what i require for
a reply, my business requirements may not be met.

I have another issue which you are probably the best person to answer. 
I noticed on the BPM groups v 2.0 draft, lines 126-131, they talk about
creating a market place (like a glorified Yellow Pages) within ebXML. 
My opinion is that ebXML should not concern itself with the specifics of
the marketplace for the following reasons:

1)  It is not a core functionality 
2)  It is not within the original mandate of EbXML
3)  It duplicates work already done (specifically by eCo)
4)  We already have enough work to do in the actual process

We defined the scope of ebXML as did other groups and there were two
areas that are specifically out of scope -  one is the original
discovery mechanism for locating another company (we are not in the
search engine business) and the second is the delivery of the actual
goods (we are not a transportation provider).  

EbXML is very much concerned with discovery of business process,
metadata, data elements and core components.  We are also concerned with
the transmission of messages concerning delivery confirmations (if that
is required by business interests). 

Lines 126-131 also state that the requirement is identical to the first
4 of 7 layers of the eco framework.  We mandated not duplicating the
efforts of others and using existing methodologies wherever possible.  I
think ebXML should not preclude such a business discovery mechanism from
being implemented but we should not do so at this stage.  I foresee the
eCo mechanism for discovery as being complementary with the ebXML
infrastructure.

Comments?

Duane Nickull


Peter Kacandes wrote:
> 
> Actually, it is quite common that a customer will send you information in whatever their native
> format is and you try as best you can to figure out if you can map it to your internal system. The
> customer doesn't give a hoot. If you are missing some particular piece of information that is
> absolutely critical, then you would go back and ask the customer for it. We do several billion
> dollars worth of business that way every year. In or business processes, there is a big difference
> between a SalesOrder (info the customer sent us in their native format) and a SalesOrderConfirmed
> (which now has all the info you need so you can execute on it). In the end, the customer still
> doesn't know and doesn't care what we call the bits of info.
> 
> regards
> 
> pk
> 
> >On page 3 you wrote:
> >
> >>>>Independence of ebXML sub-metamodels
> >
> >Although clearly interrelated, the ebXML sub-metamodels are not tightly
> >dependent on each other, and implementations of one can be very
> >beneficial even in the absence of implementations of one or more of the
> >others. <<<
> >
> >This is totally not true in the case of business process and business
> >information.  The business process is dependent on being able to specify
> >which core components (data Elements) are necessary for each party to a
> >transaction to meet their respective legal and business requirements.
> >One cannot exist effectively without the other.  I can't just say "send
> >some information to me" to place a Purchase Order.  It has to be
> >specified "Please send me the thing I call address, the thing I call
> >name, the thing I call telephone number etc.  Each of those objects has
> >to also have the ability to be referenced via a repository so the sender
> >also knows what they are.  The semantic reference from a repository
> >dictates that the RegRep access process be integrally bound to
> >potentially all transactions (at least in an abstract way - we are
> >suggesting the use of a cache in the application to ease congestion to
> >the repository query daemon).
> >
> >Also - A core component cannot be used effectively without a contextual
> >guide to allow it to be instantiated correctly depending on the business
> >process it is part of.  I can't just say Item <a> is equivalent to Item
> ><b> if there are ten places in each document where there are instances
> >of those elements.  I need to know the context in which thety are being
> >used.
> >
> >TRP as a stand alone - yes - excellent work being done there.
> >
> >I look forward to seeing more on the subject of using the UML -> XML
> >process for data elements and business processes.  This is an area we
> >are concerned about.
> >
> >Duane Nickull
> 
> Peter Kacandes
> 
> Application Planning, Architecture & Strategy   phone number:   X36529
> WWOPS IT/Supply Chain Management                email:  peter.kacandes@ebay