This is my fifth posting in this series, and I have only just got to rules discovery. That is as it should be: discovery does not lead the process but falls out of it. The scope of your decision management project has been agreed using DRAW and depicted on a DRD; you have planned the project by partitioning the scope into a number of iterations with discrete discovery tasks for all the knowledge nodes in each; you have built an empty prototype decision service to demonstrate the technical architecture is sound. Now you can start rules discovery, decision by decision, extending the functionality of the decision service as you go.
In any particular discovery task you are gathering only the knowledge required to make a particular decision at a particular point in the business process. This is what I mean by “contextualized”. So as part of the first task in my planning example you might be asking “What are the rules for deciding whether an application should be accepted, referred or declined at the post-bureau decision point?” This is a very specific question capable of being answered very precisely.
There is a substantial literature on the art of knowledge elicitation, and I don’t want to add to it, except to observe that a lot of the problems evaporate if the process is properly guided and constrained. In a nutshell, as you gather the rules you should ensure that they are:
- Complete: the set is sufficient to make a decision in all possible scenarios
- Consistent: either the rules are mutually exclusive (i.e. only one rule fires in any particular scenario) or there is some clear system for resolving conflicts (e.g. priorities associated with decision values)
- Independent: the rules do not depend on each other or on the order of evaluation.
- The rules should only determine the values relevant to the decision
- The rules should only use the data available to the decision in the DRD
If the client proposes rules which determine new decision values or use new areas of data, an extension to scope may need to be agreed.
All the above talks only about rules (well, that's what we like to talk about, isn't it), but typically many of the knowledge nodes on the DRD involve other forms of business knowledge: particularly calculations and analytic models. Calculations are very similar to rules in how they are harvested; in fact they could be represented as rules, although it is usually more convenient and closer to the business view to collect them as algorithms and implement them in functions. Analytic models are more interesting because they are the output of another Decision Management process: see Paul’s comment and my reply.
Alan, I agree absolutely that it is time for a remake of the Business Rules Manifesto. The manifesto is a reflection of rete that is no longer relevant.
ReplyDeleteYour discussion introduces decision and rules as distinct terms, but I am uncertain as to their exact meaning in the discussion - do you have a definition of these two critical terms? IDIOM offers a definition of Decision in this document bit.ly/7S9RSx that seems to align with your proposal.
I suggest that you need yet one more concept - the decision model.That is - the decision architecture is three layers deep - the Decision Model implements the business policy that responds fully to an event; the Decision is a single valued outcome determined within the Decision Model; and the Rules are the logic and constraints that determine the Decision value.
Your 'complete' and 'consistent' terms are beautifully stated, and I suggest adding 'correct'. The point being that if you can test and prove that your decision model is complete, consistent (each as you have defined) and correct, then you have proven the efficacy of the business policy. The rest of the system is now derivable from the proven knowledge in the decision model, which provides the core of any system (if it is not implementing business policy, what is it doing?). This simple sentence represents an order of magnitude reduction in risk in traditional systems development - prove the efficacy of the business value proposition first (is this even a systems development activity?), and then use this to guide all other system requirements.
Finally - I have to disagree re order. Order is critical at all three levels:
Logic within the rules - no point in assigning the truth value and then evaluating the condition;
Decisions within the model - no point in accepting the insurance risk until you have evaluated the inherent vice;
Even events are ordered - cant make an endorsement if you havent bought a policy.
These concepts all have dependencies with other elements at the same level, as well as (as you so rightly point out) context offered by the higher level concept that they exist within. Regards.
Thanks for your response, Mark.
ReplyDeleteOn your final point: yes, of course order is important between events (decision points) and between decisions, and in DRAW I capture this explicitly in process flows and the dependencies in the DRD. I was referring only to the rules used to establish a single decision. Saying that these should be order-independent is equivalent to saying they should be declaratively rather than procedurally defined. The BRE should take care of any issues of efficiency (e.g. not evaluating redundant conditions).
I have great sympathy with the notion of the Decision Model. My only problem is with your constraint that a decision can only have a single value: in most real situations a decision results in a set of data (if you like, has a vector rather than a scalar result). For example, a decision on the eligibility of an applicant for a product might consist not just of the accept/refer/decline status but also an "assessor override allowed" indicator and a list of reasons for the decision. Breaking these apart does violence to the business logic, since they are all naturally defined in the same rules. Allowing a set of data to result from a decision also greatly simplifies the model, making it possible to develop it on a whiteboard in workshops. But apart from this reservation I strongly approve of the notion of defining the decisioning as a structure of decisions and rules (and other decisioning logic) and this is what DRA is all about.
I'm not sure how you could ever prove that the rules were "correct", though, and I'm not really sure what this means. The rules are the client's definition of a requirement for decisioning. All you can do is check that they are coherent and express the client's intentions (for example, by running business simulations and checking that the decisions correspond to what the client expects). But in one sense they will almost certainly be incorrect, since they will usually be capable of improvement. Or am I missing the point?
All the best.
Alan, I appreciate your reply and I think we are very much aligned. Re your concern about scalar decision results. I agree – I neglected to mention that our decision modeling approach includes the concept of decision groups, which provide the branches of the model to any level of depth. A decision group provides the ability for multiple single valued ‘decisions’ to be collated into a multi-valued response.
ReplyDeleteAlso re your comment on correctness. I had assumed that correctness was defined by the clients, and validated by asserting correct answers for any and all use cases that the business cares to satisfy. When all proposed conditions are correctly met – where correctness is as defined by the business - then by definition the decision model is correct. Also by definition, correctness is a ‘point in time’ issue, to be ‘improved’ as changes in external conditions and internal knowledge arise.
Regards,