Standardizing Decision-Based Approaches

by FICO

(Posted by guest blogger, James Taylor)

I attended a meeting of the OMG this week and we had some good discussions that both showed the value of externalizing decisions and pointed the way for decisions to become a solid part of the OMG standards stack.

One of the first presentations was on rules-driven process modeling. There was some interesting discussion of structural rules that define state (e.g. gold customers are…) and operative rules about activity (such as when to make a customer gold or when to allow gold customers access to the warehouse). However the subsequent discussion tried, in my view, to distort how rules and processes should be managed and defined to try and unify them in some way. In fact the addition of a decision to the process and the mapping of decisions to rules would work much more simply. In the example, for instance, there are other rules like "customers can only have access to the warehouse during business hours" and a fairly complex way of managing these was proposed whereas the inclusion of a decision – "can customer have access now" - would have simplified the process and made it easier to manage the rules. This presentation made it pretty clear to me, and others I think, that rules and process can be hard to bring together if the reason the rules are in the process is not to control the process but to make decisions.

Later in the day there was a presentation on case management as a special class of processes. The point was made that case management processes are different and it is not clear how a standard like BPMN can support semi-structured and case management processes. Case management is different because it is less structured, less repeatable, data-centric and rules-based. It is not really flow based and so flow modeling is very unhelpful. Instead a more state/event and rules-based approach was proposed with lots of case-centric events taking place over time including follow-up and milestone events. These events were linked to activities using rules to control the allowed states - to define the applicability rules of activities. In this scenario decisions also work well as the decisions would be “what is expected next” and “what is allowed next” and “is case complete” defined for each kind of case. The point that both a flow-centric and a case-management-centric approach pointed to the need for decisions was not lost on anyone.

The session in which I participated was to discuss the inclusion of decisions as a formal concept in some of OMG's standards. Paul Vincent of TIBCO went first and talked about decision models and the potential value of having a formal decision model to intersect between some of the existing standards such as SBVR (Semantics of Business Vocabularies and Rules - policy rules), BMM (Business Motivation Model - strategy and tactics design) and PRR (Production Rule Representation - business rules at the execution level). I would add use cases / requirements too as the intersection between rules and requirements is best served with decisions. Larry Goldberg of KPI presented next on some of the practices and real-world experiences of KPI around decision models.

KPI's definition of a business decision is a judgment, based upon business criteria, about a business concept or about a business concept attribute that the business is interested in managing. Determine, assess, compute are all good candidate names. Larry said, and I agree, that it is critical not to just gather rules and then try and see what can be done but to focus on decisions. The KPI model of decision is purely declarative but I think that is limiting even though they are considering the platform/computational independent model. While Larry feels that any procedural stuff should be considered part of the process, I think non-simple business decision can easily have multiple steps each of which is declarative.

To the audience’s relief, I then spoke about the challenges and opportunities in using decisions, both to link process and rules and to bring data/analytics (via formats such as PMML or the Predictive Model Markup Language) into the IT mainstream. The whole group had a spirited discussion but it went very well and we ended up with broad agreement as well as some action items and suggestions.

Should business decisions be defined in BMM alongside, or instead of, business rules?
Me I think that some decisions are important enough to be modeled at a strategy level. For instance, the way a bank decides to underwrite a loan is likely to be critical to its strategy and so should be modeled along side goals etc.
The BPMN/BPDM standards are merging and should include the concept of a decision activity.
This may be simply an implementation of a certain kind of behavior but I think it deserves some kind of explicit modeling within a process.
The need to discuss decisions in the context of Use Cases was identified
It is increasingly a best practice to keep decision rules out of use cases and mapping both the use case and the rules to a decision allows for maximum clarity and reuse.
Decisions have certain characteristics in a system sense
We discussed many such as being stateless, not updating the state of the core business objects and so on.

Anyway, it was an interesting discussion and hopefully there will be a role for explicit decision definitions and/or models within the OMG business model stack. The discussion will no doubt continue in future OMG meetings before going to an RFI/RFP stage, or maybe being stealthily adapted by the existing standards. Or maybe Larry and KPI will propose the OMG adopt their model, just like the Business Rules Group did with BMM. Regardless those of us in the decision management community will keep pushing to get broader adoption of the key principles involved and so make it easier for everyone to adopt EDM.

Some other posts you might find interesting include: