3 Replies Latest reply on Mar 14, 2012 6:48 PM by rcernich

    Commitments as a way to govern business activity


      I would like to explore the possibility of using the concept of commitments, as discussed in the attached paper, as a way to understand the obligations/liabilities between principals (i.e. counterparties) in a business, whether related to internal or external participants.


      So one example could be in a financial trading context, as a means of tracking positions based on the information exchanged between the systems, without necessarily having a separate 'position manager' system that has to be explicitly notified when trades have occurred, to make the necessary calculations. So at any point in time, the organisation should be able to 'query' the governance system to understand their overall exposure to a particular party, and consequently establish governance rules to automatically initiate actions when thresholds are crossed.


      This example can be considered "business governance", but essentially uses the same infrastructure required for IT governance. It would involve modelling the commitments as part of the choreography (and/or scenarios), and monitoring runtime activity (against the principals involved) to keep track of the commitments, and a suitable UI to enable business users to access the information. So it spans from design to runtime - but also relies on Business Activity Monitoring to provide the activity management and governance rules.


      It would be good to evaluate this concept to see whether we can find a number of good use cases that would help drive the specific requirements.

        • 1. Re: Commitments as a way to govern business activity

          Hey Gary,


          So if I understand correctly, you are looking to create an abstract model that could then be applied to a variety of business cases, e.g. position management.  In that context, would the events look something like...

          • Order event [type=order, subtype=open, details[id, trader, issue, side, qty, price, dest] ]
          • Order closed event [type=order, subtype=close, details[id] ]
          • Execution event [type=order, subtype=execution, details[id, qty, price] ]


          With the monitoring piece containing logic like...

          • not dest in authorized[trader, issue] send alert("trader not authorized to trade %s at %s", issue, dest)
          • position[trader, issue] > position_limit[trader, issue] send alert("trader position limit exceeded for %s", issue)
          • position[trader] > position_limit[trader] send alert("trader position limit exceeded")
          • position > position_limit send alert("firm position limit exceeded")
          • 2. Re: Commitments as a way to govern business activity

            Hi Rob


            This is the type of thing that should be possible, although commitments have the concept of debtors and creditors in terms of the obligations, and the ability to delegate obligations, so should be possible to construct quite complex governance situations around  a definition of the high level business process (i.e. the choreography). So another example could be that, by entering into a business transaction between two parties, one party is obliged to provide legal documentation to the other - this obligation could be delegated to other parties, and the obligation may be discharged through different paths through the choreography, or even as part of different business processes (choreographies) that may be enacted at a future date.


            The problem is that my basic understanding of the concept is looking for real world examples to illustrate whether it could provide real business value. In a general sense, having the ability to essentially 'decorate' a business protocol with assertions/commitments, etc, and then optionally define business rules that can operate on that information, should provide great flexibility - as it externalises the responsibility from the actual business process. Currently a lot of this governance logic is probably built into systems, potentially being hard-coded, so unnecessary work and inflexible solution. So I feel like this would be a good general technique to support, but would be useful to identify a number of real world business problems that could be solved.


            So I think position management, or in a more general sense risk assessment between counterparties, is a good candidate solution. But would be good to find others......

            • 3. Re: Commitments as a way to govern business activity

              Well you still might have something there.  In the securities business, most transactions are "cleared" through a third party.  Depending on how the business is setup, the clearing agent may prevent a trade from occurring for various reasons (e.g. exposure).  Here's an example:


              Brokers A, B.  Clearing Firms X, Y.  B agrees to sell 100 FOO @25 to A.  The trade is reported to a trade reporting facility (TRF).  Here's where things can get interesting.

              • X does not have an agreement in place for B/Y.  The TRF rejects the trade.
              • X requires manual "lock-in" for all trades with B, clearing through Y.  A message is sent to X, asking to lock-in the trade.  The trade goes through, but may not clear.
              • X has an agreement to automatically lock-in all trades for A executed by B, clearing through Y.  The trade is accepted and should clear normally.
              • X requires manual lock-in for all trades > size.  The TRF holds up the trade, pending approval.  (In some cases, the TRF may hold up large trades, giving the clearing firm the opportunity to reject it, i.e. the TRF may also hold up the trade, depending on its policies.)

              Take the above and replace the B/Y side with each of the above (e.g. Y does not have an agreement, Y must manually lock-in, etc.).


              Each of those is an agreement between the brokers and their clearing firms, with the TRF acting as the facilitator.  The clearing firm may reject trades.


              The above is probably not exactly right, but the gist is there.


              Not sure if that helps or not.