[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Feedback from Common Business Process Group on Boston schema
I was deputized by the Boston metamodel face-to-face meeting to get feedback from the Common Business Process work group on the "specification schema" developed in Boston. Here is my report. I got most of the comments on the Wednesday CCBP-Analysis conference call. Attending the conference call were: Bob Haugen Brian Hayes David Welsh Jim Clark Jenny Xu Further comments after the conference call came from Mary Kay Blantz and Jim Clark. I will not attribute most comments to particular individuals, but as a consensus list of issues and comments. (It was a lively discussion.) Some people will be named where I thought it would help to clarify the meaning, or followup might be needed, or it was not clear that this was a consensus statement. David Welsh's slogan below was definitely consensus, I just wanted to give credit where due. 1. Comments on the diagrams in the file ebXmlSpecificationModel08.pdf included in the zip archive in the message: http://lists.ebxml.org/archives/ebxml-bp/200012/msg00029.html In the diagram on page 1, the classes Package and Package Content do not appear in the metamodel nor in any of the other submissions from the Boston meeting, nor did they make sense to the group in the context of a business collaboration. Likewise, the diagram on page 2 appeared to be a deviation from the metamodel and the other diagrams from Boston. 2. In general, names should be the same from the metamodel to the specification schema to the DTD (where the names refer to the same concept). (This was a consensus policy agreement, not specifically directed at anything in the Boston documents.) 3. There was a long discussion here which repeated those in Boston about the different termination states of a business transaction - Success, Control Failure and Business Failure - and the various causes of each. I tried to summarize this discussion, but concluded that the best summary was the suggestion during the meeting to provide a "Primer" to explain all of this stuff. 4. The name Document Transition Vehicle was disliked; the group liked the original Document Envelope better. There was a long discussion over whether double-wrapping of documents was necessary (business Document Envelope in addition to transport packaging). At the end, double-wrapping seemed to be justified for process-to-process security and multiple documents in one Envelope. 5. A related question: is Document Envelope required? Answer: yes for Requesting Activities and substantive responses, no for business signals like acknowledgments. 6. Does RosettaNet use Document Envelopes? Jim Clark says there is a similar structure with a different name. He will research what the exact name is and if there are any significant differences. 7. An unanswered question: will transferring from one e-commerce framework to another be trouble? For example, X12 or BizTalk or Commerce One or RosettaNet to ebXML. Jim Clark says that RosettaNet to ebXML will be no trouble; the others will require translators (at least). 8. All views of the metamodel should be able to be registered and retrieved from registries, not just the elements in the specification schema. The BRV and BOM views will be useful for process documentation, analysis and queries. Tracking and monitoring software may be developed using higher-level views of collaborations, if nothing else. Mary Kay Blantz: "Our vision is that companies/industries who wish to standardize their implementations would be able to find their business processes in the repository. We will recommend that they develop models and essentially 'match' the models. I don't see how this can be done if they are not using the same methodology." (This comment applies to this issue, storing all views of a business process in the repository, as well as to the issue of a standard methodology.) 9. Being able to monitor the current state of a transaction or collaboration will be critical to successful electronic business. (I interpret this as a requirement for ebXML collaboration software to keep track of the state of the collaboration.) 10. The infrastructure release with a limited specification schema should not be regarded as the end of the road for ebXML; there is a lot more to do - in particular, higher levels of collaboration such as order, fulfillment and payment. How is the infrastructure release going to be different from traditional EDI? What the added business value? There was general concern that the infrastructure release was no more capable than RosettaNet. 11. Can other methodologies be accomodated besides UMM - in particular, IDEF? The consensus was that IDEF diagrams could be derived from UMM models, but not round trips. The metamodel was too dependent on UML semantics to be completely specified in IDEF. 12. A related question: has UMM been adopted by ebXML or not? (The significance here is that the Common Business Process and Methodology subgroups have adopted UMM as their methodology.) Mary Kay Blantz: "I thought that UML (and therefore UMM) was chosen. Seems very late in the game to consider alternatives." Jim Clark: "The UMM is supported by, has incorporated the metamodel. Not the other way around. "The way to think about it is as follows. 1) The metamodel precisely defines the syntax and semantics of a business domain. 2) The patterns constrains the use of the semantics into well structured artifacts of common use. 3) The UMM prescriptively defines a set of steps to follow to assure that processes defined using the patterns are complete and well formed. "The UMM is based on or uses a set of patterns that are based on or defined by a set of semantics (metamodel). The metamodel does not require the use of a certain methodology, however the UMM has been developed to efficiently answer the questions and define the requirements that occur in eComm domain." Respectfully, Bob Haugen "ebXML is about doing business, it's not about transport." -David Welsh P.S. further comments and corrections should be directed (at least) to the BP list.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC