[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: BTP & BPM (in all its flavours)
All I am posting this now such that people can comment on the Workflow doc attached in light of the current ebXML BPSS / UMM controversy /opportunity (dependant upon your perspective). I have chosen not to copy the ebXML guys in at this point as I think this high level overview will be seen as "ignorant" - as well it might be, but I figure less fuel to the fire is prudent at this time. This is by no means an in depth report on how BTP will be or can leverage other standards surrounding the area of BPM, and should be read as a first version / draft. As agreed in the conf call this week I will work with Bill Pope and the Security guys to determine the correct level and format for the two appendices to the spec - this area Workflow and the Security area. The doc attached constitutes a start such that we understand at a high level what and where opportunities lie to collaborate, consolidate or again leverage other standards and efforts in the arena of BPM. I have read the BPSS spec and am still of the opinion that we are not in conflict with this in respect to transactions. Where there maybe some overlap / convergence / opportunity is with multi-party collaboration, Monitored Commitment, and the UMM defined business transaction Patterns UMM is not part of the ebXML standards but is used in the BPSS ). Hopefully we can get a more in-depth understanding in an informal discussion with these guys, when they have also read more about BTP. Regards, ------------------------------------------------- Mark Potts Chief Technology Officer Talking Blocks www.talkingblocks.com t. 415 255 7424 f. 415 255 7425 c. 415 606 9096 e. mailto:mark.potts@talkingblocks.com ------------------------------------------------- -----Original Message----- From: Peter Furniss [mailto:peter.furniss@choreology.com] Sent: Friday, July 06, 2001 9:27 AM To: BTP - mainlist Subject: fw from ebxml-bp: FW: What to do in phase 2: Monitored Commitments I hope Bob wanted me to forward this, 'cos I have. -----Original Message----- From: Bob Haugen [mailto:linkage@interaccess.com] Sent: 06 July 2001 16:53 To: 'ebXML-BP@llists.ebxml.org' Cc: 'Peter Furniss' Subject: What to do in phase 2: Monitored Commitments This is the first draft of a document I promised on the July 2 ebXML-BP conference call. Table of contents: 1. Short overview 2. How to make ebXML business collaborations really easy, or Declarative vs Procedural 3. A stack of binary interactions _1. Short overview: _ Q: Assuming the transaction level of BPSS is consolidated by implementors, what should the ebXML-BP team do next? A: Monitored Commitments. Monitored Commitments are also the answer to these related questions: How to make ebXML business collaborations really easy to use? How to facilitate business patterns at the collaboration level? How to start incorporating REA into BPSS? It is also part of the answer to the questions: What is better about ebXML than traditional EDI? What are the unique contributions of ebXML-BP to the current herd of candidates for business process modeling standards? _Brief definition of Monitored Commitment:_ An Economic Commitment is an REA concept defined in UMM N090R9 as "an obligation to perform an economic event (that is, transfer ownership of a specified quantity of a specified economic resource type) at some future point in time. Order line items are examples of commitments." In this proposal, I want to generalize the idea of commitment to mean a promise to perform any specified event in the future, according to specified time constraints. As in Economic Commitments, when the specified event occurs within the specified time constraints, the commitment is fulfilled. A commitment includes not only the time constraints but also (in Bill McCarthy's words) an image or detailed specification of the event that will fulfill the commitment. Comparison of the specification with the record of the candidate event will determine if the commitment is fulfilled completely, partially, or not at all. A Monitored Commitment is a mechanism that keeps track of the state of the commitment - whether it is coming due, past due, fulfilled partially or completely or unfulfilled - and can raise appropriate events and exceptions. For an inexact analogy, think of an appointment in a computer calendar that raises timely reminders. A Monitored Commitment gives us a critical element we have lacked at the ebXML-BP Collaboration level: time constraints. We have time constraints within a transaction, but no time constraints between transactions in a collaboration. Note: I am proposing Monitored Commitments here as a business requirement. I have ideas about how to implement them, but this is not an implementation proposal. However, I *do* propose that Monitored Commitments be implemented in phase 2 of ebXML-BPSS, whenever and wherever that occurs. _2. How to make ebXML business collaborations really easy, or Declarative vs Procedural_ Most of the current work on business process standards focuses on procedural choreography: transitions, guards, forks, joins, pre and posconditions, etc. While this work is necessary to implement business transactions and collaborations, I seriously doubt if business people (even business app programmers) will want to spend a lot of time on choreography, especially if they can avoid it. By contrast, the UMM transaction patterns are declarative: declare the transaction pattern you want to use (offer-acceptance), the requesting and responding documents, and maybe override some default parameters, and you're done. We made use of the declarative nature of the UMM transaction patterns by incorporating them by reference into BPSS and the BP analysis worksheets, instead of insisting that business users redefine each transaction using UML models. The business collaboration level can be made similarly declarative. (And I mean declarative from the business requirements view here.) For the most common example, order-fulfillment-settlement is a pattern that can be canned as a procedural choreography and then used in a declarative manner by businesses. However, to support declarative collaboration processes, we need time constraints between transactions. Plus we need the time constraints connected to the future events they constrain. Thus the idea of Monitored Commitments. >From a business requirements view, it should be possible to declare that a commitment has been made (for example to deliver 1000 products next Thursday at 9am) and the collaboration management software should be able to monitor the state of that commitment and raise exceptions if it is not properly fulfilled. _3. A stack of binary interactions_ Binary or two-way interactions are easy-to-understand building blocks for more complex business conversations. Request-response is the basic interaction of HTTP. Offer-Acceptance is one business transaction counterpart of Request-Response. Commitment and Fulfillment is the collaboration-level counterpart of Offer-Acceptance. Stacks of binary interactions are much closer to the design sweet spot for business conversations than procedural workflow scripts. Respectfully, Bob Haugen
BEGIN:VCARD VERSION:2.1 N:Potts;Mark FN:Mark Potts (E-mail) ORG:Talking Blocks TITLE:Chief Technology Officer TEL;WORK;VOICE:(415) 255-7424 TEL;CELL;VOICE:(415) 606-9096 TEL;WORK;FAX:(415) 255-7425 ADR;WORK:;San Francisco;10 United Nations Plaza, Suite 610;San Francisco;CA;94102;United States of America LABEL;WORK;ENCODING=QUOTED-PRINTABLE:San Francisco=0D=0A10 United Nations Plaza, Suite 610=0D=0ASan Francisco, CA= 94102=0D=0AUnited States of America EMAIL;PREF;INTERNET:mark.potts@talkingblocks.com REV:20010412T180824Z END:VCARD
OASIS Business Transactions Technical Committee - WorkflowReport.doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC