RE: Public Review of Specification Schema v0.90 and proposal for simplified design patterns.
|
John,
Thank you for the thoughtful review and response to my proposal on the simplification of the business transaction design patterns.
I would like to clarify that the main purpose of my proposal is to consolidate the 4 business transaction design patterns that include the responding document from 4 to 2 because there is no clear, testable, and easily “implement able” performance control parameter in the section 4.4 of the N090 that differentiate 3 of the 4 design patterns.
I had a different experience on the acceptance of the “Acknowledgment of Acceptance” by the RosettaNet community. The feedback that I’d heard from the Supply Chain Partners (which were represented by the business users, and not the Solution providers) on all the workshops was that they do not see a value in the additional “separate Acknowledgment of Acceptance” signal. They saw it as an overhead action, which could not be accomodated easily and is not used (or planned to be used) by their backend ERP systems. They prefer to include the “Acknowledgment of Acceptance” in the responding substantive document (just like you’d mentioned at the end of your response and like I suggest in my document) and to deal with the content non-compliance on the exception basis. This exception will be included in the responding document and returned to the requester as soon as it is discovered. This feedback was expressed by Motorola, Cisco, Bourns, Lucent and other Supply Chain partners on the RosettaNet workshops. I know that at least one Solution Provider has a solution that can accommodate the “Acknowledgment of Acceptance” parameter in their first version of the software, and I suspect that there are others that could support it as well. So, I believe that the main reason of the elimination of this signal was the feedback from the Supply Chain Partners expressed via the Solution Providers at the RNIF 2.0 development team. But this is a moot point now.
In my proposal I did include the “Acknowledgment of Acceptance” in the property values table for the design patterns with the ability to override it. At the same time I do question the necessity to have this as a separate performance control parameter based on my experience. Here is what I said in the section 4 of the document:
“Open issues for this table:
a. I left the Acknowledgement of Acceptance parameter in, but would like to recommend to consider the removal of this parameter, unless there are known existing scenarios that require the use of this parameter.”
Similar concerns were expressed by Kurt Kanaskie from Lucent. See below.
From: Kanaskie, Kurt A (Kurt) [mailto:[email protected]] Sent: Friday, February 16, 2001 12:52 PM Cc: ‘[email protected]’ Subject: RE: Public Review of Specification Schema v,0.90
Attached is my issues list with resolution notes from the meeting this morning. P.S. It was a real pleasure working with everyone face to face.
<<Comments on ebXML Business Process Specification Schema with resolutions.doc>> ________________________________________________________________ Kurt Kanaskie Lucent Technologies (610) 712-3096
Thanks for your input,
Larissa Leybovich Vitria Technology Supply Chain Solutions Irvine 949-857-4233 Cell 949-836-2545 Sunnyvale 408-212-2716
-----Original
Message-----
Larissa, BP Team, I have reviewed the document submitted by
Larissa which uses RNIF 2.0 as a basis for removing elements from the UMM,
and I would like to clarify some of the representations, especially with
respect to RNIF 2.0. The UMM is not an implementation framework, it is a business collaboration modeling framework, and as such must be able to model business operational collaborations, not just collaborations between business services. The acceptance signal is all about facilitating optimized business decisions and partner alignment. When companies integrate their operations with their partners' operations, timing and accuracy become paramount. Availability of materials within a supply chain is critical, and the process to obtain those materials must be predictable and efficient. Often business acceptance of an offer or instruction requires coordination with manual or downstream processes, which may take some time. While waiting for substantive response the requestor is losing valuable time. The responder can make the collaboration significantly more efficient by validating the request for logical, technical, and legal compliance before sending the request to a downstream partner or employee for action. The expected response time for this validation is significantly shorter than the expected time for a business response. The requester can time out on the acceptance signal within a few hours, allowing either resubmission or redirection of the request. This allows the requester more certainty and higher levels of optimization in his scheduling. So, why can't the backend system just respond quickly when a message is non-compliant? Two reasons: The first reason is that the "B2B collaboration monitor" function is waiting for the backend system as well, and will raise an exception only when substantive response is overdue; the second reason is that many backend systems would not respond for critical errors in content or format, thus constraining notification to the monitor timeout; third (and most important) reason is that one cannot know 100% of their business partners' validation constraints, and so cannot perform a robust validation step before submission. I would hope that my partner would validate the request before sending it through for action and let me know in a timely manner if it is not actionable. I would like to make business decisions based upon the knowledge that they will do so. It takes significant time to code changing business rules and legal terms into backend systems, and those rules may be dependent on previous transaction contents, which may be unavailable to a backend system but are available to a gateway rules system. Our collaboration modeling should allow for a rules system to verify acceptability of the business transactions independent of the backend systems. As such we must be able to model these interactions and their timing. We must allow independent signals from these independent systems. As business dependencies become more complex, legal considerations and compiance with corporate terms and conditions should be verified and negotiated before submission to business systems both because of complexity of legal considerations and specialization of business systems. (a point made very clear in James Bryce Clark's presentation on legal implications) The presence of the receipt and acceptance signals allow the business activities being modeled in the BOV to be exactly that: business activities. The interactions between services for non-repudiation, authentication, and compliance are removed from the business modeling, and left to implementation. If we do not allow for an independent signal for compliance, then we in effect place this into the business activity, which damages our ability to model and constrain timing of the collaboration. A robust modeling methodology should be both simplified and extended when it is mapped onto implementation specifications. Like UML on which it is based, N90 should be subclassed, specialized, and extendeded for particular uses. ebXML is all about wide adoptability of collaborative business technical specifications. UMM is all about modeling collaborative business processes. You should not constrain one because of the other, but allow each to grow dependently within their domains.
Without the acceptance signal we are modeling the collaboration of business services, with the acceptance signal we can model and optimize the collaboration between business operations.
It will be easy for the ebXML process specification to state either: 1) The acceptance is by convention returned in the response 2) The acceptance is not used at this time to allow "simple implementation" of the specification by a wide group of adoptors.
It will be much more difficult to put it back into N90 when we find our ability to align and optimize business operational processes constrained by the lack of a signal accepting compliance with legal and business rules.
My 2 cents, (thank you for listening to those that made it this far!)
Thanks! John
John Yunker Architect, Enterprise Models Edifecs The DNA of B2B (425)-895-3026 -----Original Message----- |