What to do in phase 2: Monitored Commitments

[Bob Haugen <linkage@interaccess.com>]

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