Monitored Commitment project proposal (long)

[bhaugen <linkage@interaccess.com>]

Below is revision 2 of a project proposal for the new ebTWG.
I include it here in text form; if anybody wants the MSFT Word doc,
let me know.

Dave Welsh wrote the first draft, we discussed the idea on today's
BP conference call, and I volunteered to add a section for the second
draft. (Actually, Dave, I added a detachable preamble, too...)

This is still a rough draft, will certainly go through many changes,
and may even be subsumed in a larger REA proposal later.

Nevertheless, people on today's conference call wanted to see
the next draft and discuss it on the next conference call,  on 9
August, 2001, 11:00 a.m. - 12:00 p.m.  EDT.

Respectfully submitted,
Bob Haugen

====the proposal=============

Collaboration Patterns and Monitored Commitments

Revision 1 Monday, August 06, 2001 Dave Welsh
Revision 2 Monday, August 06, 2001 Bob Haugen

Table of contents
1. Preamble
2. Rationale
3. Brief definition of Monitored Commitment
4. How to make ebXML business collaborations easy (to establish and manage),
or Declarative versus Procedural Collaboration Patterns
5. Alignment of commitment-fulfillment business process and information
models.

_Preamble_

This section will probably be modified or deleted in subsequent versions.
It is here now to frame the current discussion about this proposal.

This document is probably not in the correct form for an ebTWG proposal.  It
is a discussion document preparatory to presenting a formal proposal.

This proposal could stand alone or it could be subsumed in a larger REA
proposal, should one emerge.  Even if a larger REA proposal does emerge, it
might still be wise to start with this proposal.

While this proposal suggests generalizing the concept of Economic
Commitments as REA defines them to include other kinds of scheduled events,
it might be best to start with economic commitments.

Reasons for starting with with economic commitments and fulfillments:
* They are relatively simple.
* They can be made concrete: e.g. order line items, deliveries and payments.
* They should be well-understood from business practice.
* Order-fulfillment relationships will probably one of the most common
patterns in business collaborations (that is, they fill a business need).
* There is a business requirement for monitoring fulfillment of commitments.
* The basic concepts have already been modeled in UMM.

_Rationale_

Efficient business conversations are not only built upon transactions but
also collaborations of transactions. For example the Commitment-Fulfillment
pattern is the collaboration-level counterpart to the transaction-level
Request-Response pattern.

Monitored Commitment is a mechanism to represent and manage the state of a
commitment or obligation in a collaboration of transactions.

Monitored Commitments help answer questions:
How can ebXML business collaborations be made easy for business to use?
How to facilitate business patterns at the collaboration level?
How to start incorporating REA (the principal of commitment) with BPSS?

Monitored Commitments also in part help answer questions:
What is the compelling business case for ebXML over traditional EDI?
What are the unique contributions of ebXML-BP towards candidate proposals
promoting themselves as business process modeling standards?

_Brief definition of Monitored Commitment_

Economic Commitment, an REA concept, as defined in UMM N090R10 is an
obligation to perform an economic event (for example transfer ownership of a
specified quantity of a specified economic resource type) at some future
point in time. For example, each line item of a Purchase Order is a
commitment.

For this proposal, the work agenda will start with Economic Commitments as
defined in UMM, but also go on to generalize the idea of commitment to mean
a promise to perform any specified event in the future, according to
specified time constraints.  As with Economic Commitments, when the
specified event occurs to specification within defined time constraints, the
commitment becomes fulfilled.

A commitment includes not only time constraints but also 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.

Monitored Commitment is a mechanism to track (and manage) the state of a
commitment, whether coming due, past due, fulfilled partially or completely
or unfulfilled. Monitored Commitments will raise appropriate events and
exceptions.

Monitored Commitment also gives ebXML a critical element missing today at
the ebXML-BP Collaboration level: (temporal schema commonly called) time
constraints.  ebXML BPSS version 1.0 does have time constraints within a
transaction, but no time constraints between transactions in a
collaboration.

Monitored Commitments are being proposed as a general business requirement,
independent of specific implementation conventions of their usage. In that
sense, the work should start in UMM, building off the existing definitions
in the Business Requirements View. However, it is also proposed that
Monitored Commitments be implemented as a core theme within BPSS to support
operating business implementation.

_How to make ebXML business collaborations easy (to establish and manage),
or Declarative versus Procedural Collaboration Patterns_

Much current work on business process standards focuses on procedural
choreography:  transitions, guards, forks, joins, pre- and post-conditions,
etc.

By contrast, ebXML distinguishes itself by using UMM business transaction
patterns to make the transaction level business process model declarative
instead of procedural. IE. declare the business transaction pattern you want
to use (offer-acceptance), declare the requesting and responding documents
and maybe override some default parameters.

ebXML BPSS version 1.0 uses the declarative nature of UMM transaction
patterns by incorporating them by reference into BPSS and the BP analysis
worksheets, instead of requiring that businesses redefine each transaction
using UML models.

The business collaboration level can similarly be made declarative from the
business requirements view. For example, order-fulfillment-settlement is a
business collaboration pattern that can be declared as a procedural
choreography and then defined in a declarative manner by business; which is
a more expressive and efficient mechanism to business operations. The
concept of Monitored Commitment helps operationally manage the collaboration
pattern.

To support declarative collaboration processes, time constraints are needed
between business transactions plus the need for time constraints connected
to future events needing to be constrained.

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 collaboration management software (working with Monitored
Commitments) should be able to monitor the state of that commitment and
raise exceptions if it is not properly fulfilled.

_Alignment of commitment-fulfillment business process and information
models_

Opinion: there should be another eBTWG project to bring business process
modeling work and information modeling work (core components) in alignment.
Business Process collaborations has stages of work that requires uniform
information requirements.  Business collaborations provide a context for
re-use of core processes and core components represented in business
documents for the collaboration.

The commitment-fulfillment pattern provides an example of the need to align
BP and CC models, for example:
* Both Commitments and the Business Events that fulfill them will be
represented by Business Documents composed of information elements.
* The 'fulfillment' relationship will require a compatible set of
information elements in both the Commitment and Business Event documents,
otherwise whether the event fulfills the commitment will not be computable.
* The information elements for both commitment and fulfillment event will
need to be compatible in both structure and content.
* For example, a commitment to deliver a specified quantity of specified
products to a specified location at a specified time will need delivery
event documents that specify those same information elements in compatible
ways.
* If there are specialized information structures in the commitment (e.g.
packaging, configuration or assay requirements), those same specialized
structures will need to be mirrored in the delivery event document.
* It should be possible to define a basic minimum information model for
Economic Commitments and Economic Events that fulfill them.  This basic
minimum model would be a good basis for minimal Order Line Item documents.