Re: Definition of business process - Need for Semantics

[Ronald Grzybowski <rgrzybow@us.oracle.com>]

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.
begin:vcard 
n:Grzybowski;Ron(ald)
tel;fax:+1.650.506.7221
tel;work:+1.650.633.8084
x-mozilla-html:FALSE
url:www.oracle.com
org:e-business Program Office
version:2.1
email;internet:rgrzybow@us.oracle.com
title:Sr. Product Manager & Business Objects Evangelist
adr;quoted-printable:;;500 Oracle Parkway=0D=0A4op5;Redwood Shores;CA;94065;U.S.A.
fn:Ron(ald) Grzybowski
end:vcard