RE: ebXML metamodel write-up

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

> When you use the term "methodology" above, what use cases
> do you have in mind?  Any of the scenarios that Karsten outlined
> in the metamodel document?  Software developers using TMWG
> N90?  Business users trying to send a simple one-off purchase
> order?  All or none of the above?
> 

when i use methodology i think of all use cases concerning bp modeling 
to support the orginal vision of tmwg when it initiated the ebxml project.
this vision is documented in the attached gif-file, which was
also presented by anders as chair of the architecture pt at the
brussels opening plenary.

bob, at the beginning of the last tmwg meeting in mpls you
received a document with tmwg's vision:

---
The initiative will develop a "framework" that utilizes BPM, UML and UMM in such 
a way that any industry group or standards body, including UN/CEFACT, can create 
models that identify every possible activity to achieve a specific business 
goal.  These models will be registered and stored in a global "virtual" 
repository.  Users (trading partners - TP) will register "their" particular 
path/paths trough the model (scenario(s)) so that others who want to engage with 
that TP can determine if they share at least one scenario. To ensure that the 
models not only follow the UMM but also are interoperable, the ebXML initiative 
will provide the most common objects (Common Business Objects - CBO) that will 
be used by the modelers as they document a particular business process.  In 
addition ebXML will define the XML messaging format, packaging and routing and 
the metamodel for the repository.
---

according to the gif-file, a large company (company x) will register and
store its business models in a the virtual repository. company y (of any
particular size, e.g. a SME) buys a software that is able to query company's x
models. the software will than determine whether a common scenario exists or
not. if so, it does the actual business electronically. 

in the mission statement the following is stated: "ebxml ... creates a single
global electronic market. enables all parties irrepective of size to engage in
Internet-based electronic bussiness. provides for plug and play shrink-
wrapped solutions. this is the software i was talking above. we need more
than an xml-parser, because a mapping-based approach will always be
of the same value whether xml or any traditional edi-standard is used.


> What would "consistent results" mean across all scenarios?

so in order that a software can query company x's model in the repository,
it must be ensured that the software gets what it expects in the repository.
this means that company x's model must be conform to the meta model (and
not only to a part of the meta model). to ensure that the model is a valid
instance of the meta model, i prefer a methodology which tells me exactly
how to create valid artifacts (or instances to the meta model).

bp team was created to ensure that the business processes to be stored
in the repository follow an agreed methodology leading to consistent 
results. this methodology should start from understanding the business
domain, over the requirements definition to a design that could be used
by software developers for creating shrink-wrapped software. 
this is why tmwg has chosen to customize the rational unified process to use
a methodology which uses UML as language throughout the process and is
therefore easier to go from one step to the next. 

what i see so far in ebxml bp team is that this team mainly concentrates
on the business processes (without the data). the data part is left
to the cc team. this reminds me of good old edi. bp modeling should
guarantee that all the necessary data structures for the communication
are detected. therefore, we prefer oo-technology.



> And what methodology is proven to give consistent results for all
> scenarios under any conditions?
> 

this methodology should be identified by bp team ...

> I am not trying to defend the perfection of the BP metamodel
> here, just trying to get you to ground your statements.  I was
> involved in the discussions that gave rise to Karsten's statements 
> about selectively using parts (but not all) of the metamodel.

sorry, i have really a problem when splitting the meta model and allowing
to instantiate only a part of the meta model. bob, i understand that
REA can help me in identifying the high-level business processes. but
what does it help to the over all goal, if i only instantiate the REA
relevant parts of the meta model. so what i want bp team to show how
e.g. REA contributes to the overall goal. how is the knowledge gained
from following the REA methodology used/transformed in a design phase.

> I thought the statements were aimed at business users of
> ebXML who had limited goals.  

i think here is the great misunderstanding: what means limited goals?
for me a ambitious goal is to store the own models. a limited goal is
to accept the models from somebody else. so in the second case i do
not perform any modelling at all.


looking forward to discussions in san jose - since i will not be
able to answer any replies until the meeting.

christian

vision.gif