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