RE: Definition of business process - Need for Semantics

[Cory Casanave <cory-c@dataaccess.com>]

Christan,
We are more on-track than you think.  When I refer to specification, I am
referring to a precise specification of the full b2b business process - not
just the external artifacts (E.G. DTD).  This includes semantics such as
schema, constraints, dependencies, types and sequencing .  Behind this
specification (or model) is a Meta-model of the process and information
exposed within the process.  This Meta-model may be expressed in UML or
textual forms (even an XML form would be possible).  This specification is
the end result of -some- process, probably modeling but is independent of
the modeling methodology.  It is this distinction between this precise
end-result specification (which is also a model - even Java has a model) and
the modeling process that I was trying to make more clear (but perhaps made
less so).  

So, absolutely - there is a Meta model and that Meta model drives the
external artifacts and the rest of the technical architecture.  You can call
instances of that Meta-model  a model, a specification, a language...
whatever makes the concept more clear.

We also need to make it clear that while the b2b business process does tend
to flow back into the business, it is not necessary to have exactly the same
model exposed internally - some adaptation is possible.  It is this
adaptation that removes the requirement to "model the business" or change
the business to use the external system.

So, I think we are in violent agreement.

Cory

> -----Original Message-----
> From:	Ronald Grzybowski [SMTP:rgrzybow@us.oracle.com]
> Sent:	Saturday, February 12, 2000 4:50 PM
> To:	Christian Huemer
> Cc:	cory-c@dataaccess.com; ebxml-bp@lists.oasis-open.org;
> ebxml-core@lists.oasis-open.org; un-tmwg-tg5@sfo.harbinger.com;
> linkage@interaccess.com
> Subject:	Re: Definition of business process - Need for Semantics
> 
> Christian,
> 
> I agree that ebXML must provide some kind of "minimal semantical
> requirements for
> mostly used business objects" in order to be of practical value.
> 
> Most of the time spent for Enterprise Applications Integration goes into
> semantical transformations of business events (like XML structured message
> payloads) between different applications sytems. Providing a meta model
> for
> business process descriptions is very helpful, but to save much time in
> integrating business processes (B2B protocols can be thought of as planned
> business processes) across different business applications, we should try
> to
> identify a set of extensible, essential business objects and/or business
> document
> specifications as a semantical foundation.
> 
> Regards,
> Ron(ald)
> 
> Christian Huemer wrote:
> 
> > > It may be better to position ebXML as having a specification (not
> model) of
> > > the externally visible (e-) business process.  While the internal
> business
> > > process must, logically, "fit" or be fitted to this external
> specification
> > > it does not have to be an extension of it from the modeling
> perspective.
> > > Specifically, there would be no requirement to model internal
> processes to
> > > adhere to the external specification.  Modeling is usually thought of
> as a
> > > process of discovery, which may be miss-leading to the users of ebXML.
> > > Those creating a new process specification (E.G. SWIFT) will probably
> have
> > > to "model" some process so as to specify it, but that modeling may not
> be
> > > formal or visible in the final result.
> > >
> > > Note that this distinction is somewhat soft, but may better
> communicate the
> > > intent and reduce fears that users would have to model their business
> to use
> > > ebXML.  An ebXML process specification should not have to be large,
> complex
> > > or a burden (Most b2b processes are quite simple).
> >
> > hi cory,
> >
> > it seems that we are coming from two different directions.
> > but, i think that is quite usual when tmwg/edi and xml people
> > start talking.
> >
> > to understand the tmwg position, i would ask you to read
> > the document "tmwg recommendations on xml" (especially '5
> > of the abstract - page 3 and 1.8 and 1.9 on pages 10/11).
> > you find a pdf version of this document on the bottom
> > of the ebxml documents page.
> >
> > why do we think that business models should not result
> > in just one artifact, which is the external specification?
> > this approach has been taken in traditional edi standards
> > as edifact or x12. ok - those standards do not use markups,
> > data is implicitly identified by the order. many people
> > may think that tagging by itself is the solution. i do not
> > agree. a tag name is a hint for the programmer. the semantically
> > full definition must be defined somewhere else. the same
> > is true in traditional edi standards. i have to look into
> > the directory to get the meaning of the 3rd element of a
> > certain data element.
> >
> > so who are the ones that have to look up that information?
> > in your mail you mention that users might fear modelling.
> > so i guess you mean that the end users will look up that
> > information ( i am sure that they fear modelling :-) )
> >
> > that is also the way that traditional edi standards are
> > going. end users use independent software which uses
> > its own in-house structure. since no translation software
> > can guess the in-house structure, there is no plug and
> > play solution available. the end users have to do
> > the mapping themselves. that works for large companies,
> > because as hubs they have to support only a few
> > message implementation guidelines. furhermore they usually
> > have more resources to do the mapping. but what about
> > the SME. they are the ones who whether have the know-how
> > nor the money to do the mapping.
> >
> > so if we use xml as syntax instead of un/edifact or x12,
> > and the companies still have to do the mapping between
> > in-house data and xml of their own, ebxml might be a
> > standard framework which by no way better than un/edifact
> > or x12.
> >
> > so the ebXML initiative is focused not only on "corporate
> > america" but also on all SMEs around the globe. therefore,
> > i think ebXML will only be successful, if SMEs are reliefed
> > from the burden of the mapping process. this means that
> > inexpensive software which allows interchanging without
> > prior agreements must be available. accordingly business
> > solution software providers have to include modules into
> > their software- which are 'ebXML'-compliant (or at least
> > compliant to some ebXML business transactions) and will
> > be responsible for the communication and internal integration
> > aspects of the software.
> >
> > what does that all mean to modelling?
> > the users of the models are not the end-users. the users of
> > the models are the software providers, the programmers who
> > are responsible for delivering the above mentioned modules.
> > and programmers should not be afraid of UML models. The
> > UML models rather help the programmer in implementing the
> > project - yes it is software engineering.
> >
> > hope this helps in clarifying my point of view.
> > if i find time in april i will write a paper on that topic,
> > to formulate may arguments more clearly (and in a better
> > English ;-) )
> >
> > i think that this is a really substantial topic for ebXML.
> > and a decision whatever way to follow should not be made
> > after the bruxelles meeting. i think it should better
> > be made today - because it really influences the work to
> > be done, e.g. the meta-model of the business process team
> > mainly depends  on the artifacts to be stored. and i guess
> > the architecture should not be independent of the decision.
> >
> > btw, Bob we did not change our name because we want to concentrate
> > on business modelling (if so we would be the business
> > process modelling project team :-) ). rather it is true
> > that we wanted to get rid of 'methodology'. because the
> > decision was made that we not create/select a methodology
> > to produce the artifacts of the business modelling phase.
> > we just want to define a meta-model that is able to
> > capture the artifacts. the question is now: which artifacts
> > would that be?
> >
> > christian
> >
> > p.s.: klaus, can you - as chair of ebXML - help us on this topic.
> >       because, i want to prevent myself from setting up a wonderful
> >       meta-model which can cover a lot of artifacts, but it has
> >       already been decided to store just the external static
> >       specifications. << File: Card for Ronald Grzybowski >>