[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Definition of business process
> 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC