Re: Business Process team Preliminary Document

["Lisa M. Shreve" <lms@wwnet.com>]

Martin & Bob,

Martin raise's a good point - there is a gaping disconnect between the work efforts of Core
Components and the Business Process PT, and it is a priority to correct next week in
Brussels.  This has come about through no deliberate actions of either group, but is more of
an artifact from having all of the project teams start at once.  Each group has had to spend
time internally, working as a project team on its own deliverables ... the requirements
document hasn't even been approved!

In our efforts in core components, we have made cross industry interoperability and
reusability, while preserving crystal clear semantics, the highest priority.  Considerable
progress has been made in this area, and we are committed to work with the Business Process
PT on achieving these critical objectives.  I believe this is consistent with the
requirements document, although not stated in these words.

lms

Bob Haugen wrote:

> Hi Martin,
>
> As a member of the Business Process team and also
> Core Components, I can respond to your issues to some
> extent.  I'm copying the BP list on this message, too -
> hope you don't mind.  They need the issues.
>
> I put your last issue first because I agree with you
> (although I am not speaking for the BP group in any
> official capacity here, just expressing my own opinion):
>
> Martin Bryan wrote:
> >I note with dismay that the scenario proposed by the Business Process group
> >"assumes for simplicity that none of the parts of the business model are yet
> >in the repository and that the organization(s) designing it are willing to retrofit
> >their applications to fit the new model." What I thought we were trying to do was
> >to stop people starting from scatch or from their own proprietary solutions,
> >encouraging them wherever possible to start from an existing sets of core
> >components rather than their existing set of information entities!
>
>  I think you are correct that core components should either be part of the
> "New Business Model" scenario or a separate scenario should be written
> explicitly using core components.
>
> There are several scenarios in the document - the one you quoted is only
> one possibility.  There is another one called "Conversion" that assumes
> a business model that pre-dated ebXML.
>
> I have no immediate response to your other issues, which
> seem to me to require more discussion between BP and CC groups,
> especially the relationships between Business Signals and
> Business Documents. Maybe this can happen in Brussels.
>
> So I just quoted your statements below in order to present them
> to tbe BP list.
>
> Regards,
> Bob Haugen
>
> More issues for the BP group from Martin Bryan of Core Components:
> >I am worried about the way the Business Process team see the role of Information
> >Entities within Business Documents. It would seem that what they refer to as
> >Fundamental Information Entities are what we refer to as Core Components, which
> >are the things they have stored in Dictionaries The definitions of how these would
> >be used in Business Documents seem wrong to me. Their current definitions are:
>
> >Business Document.
> >A business document is the description of a particular entity within a business,
> >or the description of an agreement between organizations, or the description of
> >an business event. So the document is never the 'real' thing, just a description of it.
> >A business document is the central component of any information exchange
> >among partner roles.
>
> >Information Entity.
> >An information entity is a primitive or complex data structure. We haven't defined
> >this yet, but it may be that the difference between a data structure and an
> >information entity is that the information entity also contains business rules about
> >the data.
>
> >Fundamental Information Entity.
> >A Fundamental Information Entity is in essence a data type. In business contexts
> >we might need many more 'data types' with business semantics beyond the
> >standard data types of 'int', float' etc.
>
> >Dictionary.
> >(Consider how core components organize terms in the dictionary for optimal re-use.)
> >The dictionary should contain data types, re-usable components, and the templates
> >(DTD's) of the business documents, but not the documents themselves.
>
> >I would prefer to have definitions more along the following lines:
>
> >Dictionary
> >The Dictionary contains re-usable components, including fundamental information
> >entities, enumerated code lists, data type representation specifications and templates
> >for business documents (e.g. DTDs and Schemas).
>
> >Fundamental Information Entity.
> >A Fundamental Information Entity is a reusable unit of exchangeable information,
> >together with a set of rules defining constraints on its content (e.g. it conforms to
> >a named data type representation or has a value from a named enumerated code list).
>
> >Information Entity.
> >An Information Entity defines a processable unit of information within a business
> >document. It can have either a simple (single component) or a complex (multiple
> >component) data structure. Where possible it should consist  of one or more
> >Fundamental Information Entities. Information Entities can be constrained in terms
> >of both their contents (e.g. the set of permitted components in a complex data
> >structure) and in the relationships between information entities (e.g. if this entity
> >contains component X with contents y then that entity must contain component A
> >with contents B within the same document entity).
>
> >Business Document.
> >A Business Document is a set of Information Entities that is exchanged between
> >Partners as a Business Signal relating to a particular Business Process Interface.
> >A Business Document is the central component of any information exchange
> >among Partners.
>
> >(Other forms of "business document" might include the description of a particular
> >entity within a business, or the description of an agreement between organizations,
> >etc, but such documents are not used directly as business signals. The above
> >definition applies only to documents that contain information of relevance to a
> >business event.)