Ron Ross, Jacob and I have recently been discussing the March DMC Challenge. In his submission Ron suggests the challenge is a ‘rules problem’ not a ‘decision problem’ and quite reasonably asked me for my definition of a ‘decision’ when I said I didn’t agree with his assessment. Jacob suggested I post this (which is a slightly edited version of my answer to Ron’s question) to provoke a little discussion, to see what others in the community think.
To start, I certainly don’t follow the DMN definitions, I must be honest, I’m not sure I’d ever actually read them before Ron helpfully included them in an e-mail. And I must agree with Ron they are a bit slack for something which purports to be a formal specification. Quoting from the spec:
- Decision: The act of determining an output value from a number of input values, using decision logic defining how the output is determined from the inputs.
- Decision Logic: The logic used to make decisions, defined in DMN as the value expressions of decisions and business knowledge models and represented visually as boxed expressions.
These key definitions seem a wee bit circular, incomplete (in particular, ‘value expressions’ are not defined in the glossary, nor as far as Ron and I can tell anywhere else in the specification, although it is used 54 times). I’d also argue the definitions read (even if this is unintentional) as needlessly restrictive.
I looked up the definition of ‘decision’ first in my own dictionary, and then a few online ones. I was relieved to find they all agree with what I learnt as a child (though some are charmingly circular ‘a decision is the act of deciding …’) and they boil down to the following which you can take as my definition of a decision:
Decision: a noun, meaning: the act of making a making a choice between (a number of) alternatives.
A few immediate points.
Firstly, a decision is defined as an ‘act’ in its common English usage. Ron points out that this is just one of multiple commonly-understood meanings for ‘decision’ and that it is not the best choice in this context because it connotes procedure or process rather than promoting a declarative view. As explained below, I don’t agree with him, because declarative approaches (and procedure and process) lie in the ‘choice’, not the ‘act’.
Secondly as Ron has pointed out to me, among the other meanings of ‘decision’ is to denote the chosen alternative. One could say then, that a ‘decision’ is an outcome (quoting from Ron’s preferred dictionary definition ‘a determination arrived at after consideration’). But this doesn’t actually take us anywhere new, because we can only get the decision as ‘determination’ after an explicit decision as an ‘act’, so the ‘act’ part is still in play even if we try and use this definition. I see no more declarative (or procedural) aspects are found using the outcome definition than in the ‘act’ definition.
Finally, as a definition, it’s almost useless for our purposes as members (or clients) of the Decision Management and Business Rules Communities (henceforth ‘the community’), as is apparent if we look at a couple of daily decisions ‘chez Bob’.
- I go downstairs in the morning. I now need to make a decision (‘act’) whether to have some tasty homemade granola or a boiled egg for breakfast. My decision (‘determination’) is to have the granola
- Monty, the family cat sticks his head out of the cat-flap and peers into our back garden. He now has to make a decision whether to go out into the garden or go back into the kitchen and eat more of his food. Monty’s decision (‘determination’) is to have more food.
What’s wrong is pretty obvious. We, the community, are interested, not really in the ‘act’ part of the definition of decision, but in the ‘choice’ part. We want to ask questions like: what are our alternatives? why do we choose one alternative over another? which is the ‘best’ alternative? and so on. But for the decisions above, no-one, even Monty the cat, or I are going to give a real explanation of how we make our choice, because no-one understands in general how brains make decisions.
(Note: this is not to say the ‘act’ part is not important – as I can testify having faced at least as many challenges creating operational decision systems as a solution architect as I have in modelling the decisions and determining the appropriate business rules as analyst and rules architect).
In my view the community is interested in decisions where we can characterise how the ‘choice’ is made, so what we need is not a definition of ‘decision’, but a definition of a subclass which identifies ‘interesting’ decisions. For want of better terminology, I will call a decision ‘of interest’ to the community a ‘business decision’, and propose the following definition:
- Business Decision: a (qualified) noun, meaning: the act of making a choice between (a number of) alternatives using a consistent, well-defined method to determine the chosen alternative.
And to pair this up with the DMN decisions above we additionally define:
- Business Decision Logic: a (qualified) noun, meaning: the consistent, well-defined method to determine the chosen alternative used in making a business decision.
(note this does not lead to a circular definition, it just provides us with a synonym for the ‘method’ part of the first definition).
I’ve chosen an open definition for ‘Business Decision Logic’ because as far as I am concerned you can choose whatever method you like. The DMN definition’s talk of ‘value expressions’ and ‘boxed expressions’ seems to be trying to tie down DMN so it can only be used for modelling decisions automated using rules. But in fact, DMN also permits you to model manual processes with no automation, partially automated systems and allows the use of more exotic techniques (predictive analytics, constraint engines and so on) as well as rules when you are automating things.
For me ‘Business Decision Logic’ could be: some declarative rules; some code; some predictive analytics; some handwritten standard operating procedures. You can even use a crystal ball if you like. I don’t demand that the method gives consistent results – it could involve rolling a dice. I only demand that there is a well-defined method, and you consistently use that method. The definition does not call explicitly for inputs and outputs, but implicitly there are outputs (the alternative choices), and almost certainly there are inputs as well (for example what you threw with the dice).
To try and make my stance perfectly clear a couple of examples of what would I regard as a business decision following these definitions. I hope the first is non-contentious, the second is deliberately contentious:
- I go into a bank, I ask if I can have a loan, the helpful bank clerk asks me some questions, and then goes through some kind of evaluation process and gives me an answer to my request for the loan which (forgetting about other details) will be either ‘yes’, or ‘no’.
- My computer executes the instruction jz L1 (this is the Intel chip assembler code for ‘jump to label L1 if the zero flag is set to 1’), and either executes the instruction at label L1 or executes the next instruction in memory as appropriate.
The first example seems almost the standard example of a decision made by a business – it’s certainly the standard example which sits at the heart of the DMN specification. I would argue if you accept the first example as a business decision, you must accept the second as a business decision too (even though the qualification ‘business’ here is wildly inappropriate). The method in the first case typically involves (manual) standard operating procedures, business rules, predictive analytics and third-party data. In the second, it is physically embedded in the arrangements of transistors on a chip, but in both cases, there is a method that is both well-defined and consistently applied.
What I would (probably naively) hope is that using definitions like this might defuse some of the tension between the ‘Business Rules’ and the ‘Decision Management’ communities, because there seems to be a tendency to conflate the concept of ‘rules’ and ‘decisions’ where to my mind they are fundamentally different.
As defined above a ‘business decision’ is an active concept. To make a ‘determination’ you need an ‘act’. Conversely, ‘business decision logic’ is in a sense passive. The ‘business decision logic’ (the ‘method’) sits waiting until it called into use when the ‘act’ takes place. While the two are certainly related, in my view when we talk about ‘Business Rules’ we are talking about a (very major) subclass of ‘Business Decision Logic’ – which may in principle apply to lots of ‘Business Decisions’. ‘Business Decisions’ on the other hand involve (possibly procedural) machinery in order to perform an action, which activates this logic and establishes the outcome determination.
But what does everyone else think?
Dr. Bob Moore
I shared my point of view in this post “A Formal Definition of Operational Business Decision” – see https://openrules.wordpress.com/2019/03/15/a-formal-definition-of-operational-business-decision/. It may sound “shocking”, but I hope it may lead to an automatically generated execution mechanism that will at least partially address Ron’s challenge. So, I’d be glad to hear constructive critique and specific suggestions.
Jacob, it’s an interesting viewpoint (certainly not ‘shocking’) and possibly a useful one in some circumstances, but my immediate feeling is that its applicability is much more limited than you suggest.
While going from a CSP to a set of rules which compute a solution is fairly straightforward, the reverse process is only possible in particular circumstances. My own gut feel is that the cases where this is possible represents a fairly small subset of operational business decisions rather than the ‘majority’ as you suggest.
You’ve demonstrated that this is possible with ‘The Decision Model’ (TDM), and TDM is impressively powerful in terms of ensuring that rules are consistent, complete and robust. This however is only achieved at the cost of some expressive power, something I experienced when using it on a real project. By contrast, rule languages as provided by tools like Blaze Advisor, ODM and Drools are for practical purposes ‘Turing complete’, so can capture and express decision logic which falls well outside the remit of CSPs. When I’ve been building rule based solutions for clients over the past 30 years or so, I think I’ve almost always been obliged to step outside what could be expressed as a CSP in order to get something into production which will actually meet the requirements.
Your definition also excludes decisions which are not rule based but incorporate other decision techniques like neural networks, predictive analytics and procedural logic, as well as those which can involve some level of manual intervention (from a ‘type’ perspective if not a ‘quantity’ perspective the vast majority of operational business decisions are actually purely manual and are not even ‘business decisions’ in the sense I defined in my original post)
A second problem, is that even if I restrict myself to purely rule based decisions, if I want to express my decision-making logic as a CSP, how do I know if it is even possible? What are the rules(!) which allow me to determine when a set of rules can be cast as a CSP? From your own comments, problems seem to arise when the domain model for the decision starts becoming complex with collections of entities which either need to be looked at iteratively or need to be aggregated.
Ironically, I strongly suspect that it may be possible to frame the at least qa significant part of the rules component of the Organ Donation Problem – which provoked this discussion in the first place – as a CSP despite the fact the state involves a non-trivial domain model. I’m just not sure I want to spend the time working out if I am right or not.
From a practical perspective, I think that we (Decision Management and/or Business Rules practitioners), have actually grabbed the low hanging fruit. We know how to manage most of the moderately simple, low value, high volume ‘operational business decisions’ already – even if a lot of businesses still have failed to take advantage this. We can probably frame several of these as CSPs – but I’m not sure what benefits we would accrue, given we already have developed more pragmatic ways of addressing them. On the other hand, as we turn attention to more complex decisions, I’m pretty sure most of the problems we encounter – even if we can treat them as pure rules problems rather than calling in additional decisioning mechanisms – will have domain models and logic requirements which take us beyond what we can express as a CSP.
I’d agree with your reasoning about the limitations of my definition assuming that it deals only with Constraint Satisfaction Problems (CSP) that can be solved by a constraint or linear solver. BUT IT IS NOT!
My definition considers a decision as a solution to an operational business problem defined by a set of variables and a set of rules. It says nothing about variable types: they can be known or unknown, numerical, textual, logical, lists, sets, maps, etc. This definition doesn’t assume anything about rules beyond the fact that they define relationships between different variables. These relationships can be specified by decision tables, state machines, if-then-else, filters, loops, any complex combination of various rules or by any function in any programming language. Some problems may include optimization objectives and others not.
More importantly, it assumes nothing about ‘HOW’ how decisions will be produced. It means decisions can be found by applying any rule engine, a DMN engine, a constraint or MIP solver, a custom piece of software written in any programming language, a manually provided decision, or their various combinations. Yes, this problem definition assumes that its problem resolution mechanism can use any program written in Java, Python, R, etc. or even a complex interactive application. So, it’s hard to give an example of a practical business problem for which we need routinely make business decisions and that goes beyond this definition.
Why did I mention CSP? Because Ron challenges all of us to provide a mechanism to automatically solve well-defined operational business problems (using e.g. SBVR or enhanced DMN modeling constructs). I have my doubts that it’s possible (at least today) for such generic problem definition. However, if we limit the problem definition to a certain type of variables and rules, we can do it. For example, my 2011 paper proves that if we consider problems compliant with TDM, we may automatically(!) convert them to a CSP that will be solved by an off-the-shelf solver. My recent solutions for Vacation Days and Flight Rebooking challenges, go beyond this approach and show how to apply a combination of a rule engine and a constraint solver (but it still requires a “coder” in Ron’s terms). Soon I plan to publish a similar solution for the much more complex Balanced Assignment challenge.
To go beyond “the low hanging fruit”, it makes sense to consider different problem domains like CSP and beyond – you mentioned a few. Hopefully, after we as a Community develop automatic solvers for different problem domains, we will be able to talk about a “universal” problem solver. We also should pay more attention to recent advances in Rules Reasoning (semantic web) techniques. BTW, DecisionCAMP-2019 is co-located with RuleML+RR gives us with this opportunity.