Proposal for specifying business collaborations in business terms

[Bob Haugen <linkage@interaccess.com>]

This message is a followup to my previous message about "Economic relationships in business collaborations".  It contains an attached class diagram in GIF format and this description.  Like the previous message, this one is long and maybe difficult.  I believe the contents will repay the effort.

The goal of this proposal is to enable business people to be able specify ebXML business collaborations in business rather than technical terms.  I will send another message, entitled "Xtreme Ease-of-Use", which describes a potention application of this proposal.

The proposal builds on Bill McCarthy's REA business ontology, which represents 20-plus years of distilling economic relationships down to the smallest possible number of moving parts. (Please do not be put off by the slightly pretentious word, "ontology".  It just means the model of concepts and relationships that define a domain, in this case, business - or in other words, the vocabulary and what it means.  Ontology will be the basis of the Semantic Web, of which you may have heard.  In other words, the Internet business relationships of the future will based on shared ontologies.)

McCarthy's REA concepts are embedded in the ebXML metamodel as the Economic Elements - see Figures 6 & 7 in the Collaboration Modeling Metamodel at:
http://www.ebxml.org/project_teams/business_process/wip/

In my class diagram, I have extended Figures 6 & 7 in several ways, which I'll explain below.  My extensions (if approved) need to be put back into the metamodel.

The class diagram is very raw.  I'm sending it to get a conversation going. The relationships with business collaboration objects will be like those in Figure 7 of the current metamodel document.  

There are my two main ideas: 
1. ebXML runtime software should be separated into at least two service levels: 
    * Business Transaction software, that manages the Business Transaction patterns
      defined the UN/CEFACT UMM N90 document. (I hereby suggest to Paul Levine
      that these patterns be extracted into a separate document and published on
      the BP WIP page for public consumption.)
    * Business Collaboration software, that manages Business Collaborations, which
      consist of related groups of Business Transactions.
      The Business Collaborations should keep track of the state of the collaboration.  
      This will require two levels of XML:  one to represent the collaboration model, 
      another to represent the state of a collaboration instance. 
      These two levels are represented in my class diagrams by blue and yellow
      background rectangles.
2. Most ebXML collaborations will be about procurement, and the central pattern for procurement is some variation of order-fulfillment.  Therefore order-fulfillment patterns should be supported directly by ebXML as are the common commercial transaction patterns.  This means that the Business Collaboration software should include classes as in my class diagram, to support a vocabulary for modeling order-fulfillment patterns.  I do *not* mean that the patterns themselves should be baked into the software, just the classes and relationships for representing them directly in business terms.


A little more detail

The runtime software for managing Business Collaborations could be different from that for managing Commercial Transactions, more like a higher service level that uses the Commercial  Transaction runtime to execute its transactions.

The runtime model for Business Collaborations (as opposed to Commercial Transactions) should have two levels, a mapping level or the Business Collaboration model, and the instance level or the Business Collaboration state.  Both levels can be described and saved as XML documents, but at runtime, they should be constituted as program objects with methods that use the elements of the XML documents as their own properties.  (Note to Stefano Pogliani:  the mapTo expressions could also be SQL or legacy system API expressions.)

Both levels of the diagram focus on the economic elements and relationships involved in order-fulfillment patterns.  This means that users of ebXML business collaboration software can get order-fulfillment behavior built-in, without modeling, analysis or programming (or, "leave the modeling to us", it's already been done).

The mapTo properties of the map-level objects contain expressions which the instance-level objects can use to map between the order-fulfillment objects and their associated XML BusinessDocuments.  Most of what the business users need to do is plug in which XML documents will be associated with which order-fulfillment specs, and which elements of the document are mapped to which properties of the related order-fulfillment spec.

The result will be that the order-fulfillment and other related business collaboration patterns can be modeled as business processes that can be re-used regardless of which business documents are used.  Also, new related business processed can be specified in terms of Orders, LineItems, Invoices, etc., instead of sequencing rules and other programming-language-style elocutions.

There is one other set of specifications that I have not yet modeled, and that is what to do when something goes wrong from a business viewpoint.  The general outline for business problems is that things can go wrong in the following situations:
. Order negotiation:  modeled in a separate pattern, not shown here, except that the NegotationStates shown here would be used.
. Order fulfillment:  the following problems can occur:
  . Incorrect ResourceType
  . DateTime too early or late
  . Quantity too much or too little
  . Quality problems, e.g. damage
. Compensation problems:  basically the same problems can occur as above.

What can be done about it (thanks to Jim Clark):
. Remedies - rectify the problem condition.
. Claims - execute a claim against the party that caused the problem condition, either directly or through an agency.
. Penalties.
. Indemnification - the party that suffered the problem excuses the party that caused the problem.

All of the above should be handled automatically by the Business Collaboration software, according to parameters specified in the Business Collaboration Model.

Please send constructive criticism.

Respectfully,
Bob Haugen