RE: Definition of business process

[Christian Huemer <ch@ifs.univie.ac.at>]

> 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.