In BRS Question Charts (Q-Charts^TM) we refer to an operational business decision by the question it answers (a very nifty idea we pioneered). Does that mean a decision is a question? Shouldn’t decision refer either to the answering of a question or to the answer itself? To be clear, we definitely do not think or say that the question is the same as the decision. However, if decision is understood properly in a business rules sense (the trick), there is only one question[1] a decision answers. So as a (very) convenient shorthand, you can use the question as the name of the decision. With that issue aside, so which should decision refer to, the answering of a question or the answer itself? The dictionary will support you either way you go. From MWUD[2]:

1a: the act of deciding

1b: a determination arrived at after consideration : SETTLEMENT, CONCLUSION

If you’re a process person, you’d probably pick the first definition. But if you’re a true business rules person, you have to pick the second. From a business rules perspective, a decision is the answer (conclusion) you produce, not the act of producing it. The “act of” is something else altogether.[3] So a decision is an answer. But is answer alone enough? No. Digging a little deeper into MWUD we find these definitions:

determination [2]: the resolving of a question by argument or reasoning

decide [c] to infer or conclude from available indications and evidence

Here’s the point. For business rules it’s crucial to capture the logic path (reasoning, inferences) that gets you to the answer. To say that differently, for business rules just knowing the conclusion isn’t very useful; the determination must be directly traceable (from conditions or cases to conclusions or outcomes, and vice versa). So focusing on answer in isolation for decision doesn’t quite get you where you want to be. The bigger picture is that the answers are traceable. www.BRSolutions.com

In a recent blog post I called attention to the fact that there’s a major collision of terminology with respect to the term decision as used by different communities. See: http://www.brsolutions.com/2014/07/06/a-note-to-business-analysts-about-%e2%80%98decision%e2%80%99/ My basic observation was that both communities are correct in their own context – but since the contexts intersect the result is a significant potential for confusion.

• Business Analyst Community. Decision is often used in talking about business analysts’ own work – i.e., what methods to use, go/no-go on change, tool selection, choice of elicitation approach, etc. Its usage also seems to cover the sense of “management decision” – e.g., what course should project work take.
• General Business Community. Decision always refers to a determination in business activity – e.g., should this applicant be given a mortgage, what should be charged for shipping an order, etc. This is the focus of decision in the business rules / decision engineering community.

Let me make some additional observations. A first question one should ask to clarify decision is what is the time horizon? Is it strategic or operational? A second question one should ask is what does decision actually refer to when used by each community for a given time horizon? Table. What Decision Refers to Based on Community and Time Horizon

Time Horizon of Decision	General Business Community	Business Analysis Community
strategic	strategic business decision	strategic project decision or change initiative decision or option analysis
operational	operational business decision	—

  In contrast to operational decisions, strategic decisions are always longer in time horizon, and generally made only once (which isn’t to say they can’t be revisited sometimes). This point is true for both communities. The distinguishing characteristics of an operational business decision is that it:

• Is highly repetitive (100s, 1000s, or more per day, hour, etc.).
• Can be encoded as practicable business rules.

Note: My analysis doesn’t address operational decisions for the Business Analysis Community (the cell show with dashes). That’s not because decision isn’t applicable in that context, but rather simply because it’s outside the scope of the present discussion. I recently saw the following draft definition of decision, which illustrates the problem of mixed meanings quite clearly.

An activity to answer a question or select an option from a known or knowable set of possible options. Typically defined in terms of business rules and made in response to events or at defined points in a business process.

• The first part of the definition is reasonable for decision in any usage. It applies to both communities and to any time horizon.
• The second part of the definition pertains only to the meaning of operational business decision. Strategic decisions, whether for the General Business Community or for the Business Analysis Community, are generally not based on specific business rules and are not made in response to events or at defined points in a business process. Strategic decisions are simply different in kind from operational business decisions.

The focus of a strategic decision is also quite different for each of the two communities.

• General Business Community: The focus is on conducting future business in a certain way.
• Business Analysis Community. The focus is on conducting a proposed initiative in a certain way to change the business itself.

Bottom Line: For clarity, I would always qualify decision to indicate which kind is meant. We certainly don’t need any more confusion in business engineering than already exists! www.BRSolutions.com

Perhaps the following point about the term decision is already clear to all, but at the risk of stating the obvious, I’ll make it anyway. There’s a major collision of terminology with respect to decision as used by different communities.    

• In the business analyst community, decision is often used in talking about business analysts’ own work – i.e., what methods to use, go/no-go on change, tool selection, choice of elicitation approach, etc. Its usage also seems to cover the sense of “management decision” – e.g., what course should project work take.
• In the larger business community, decision always refers to a determination in business activity – e.g., should this applicant be given a mortgage, what should be charged for shipping an order, etc. This is the focus of decision in the business rules / decision engineering community.

In the context of their own communities both usages are correct. Unfortunately, the collision often results in confusion about the appropriate focus – and about which methods to use – for both audiences. In situations such as this, the best practice is to define the concept in question for each community. Terms considered to be obvious usually aren’t. It’s not clear to me that this has been done explicitly in the business analyst community. Another best practice is to qualify the term every time it’s used. So we always say operational business decision when talking about the business context, not just decision. That also distinguishes the concept we mean from other potential sources of confusion – e.g., strategic business decisions and system-level decisions or IT decisions. I believe what the business analyst community means by decision is strategic project decision or strategic change decision. But I can’t really be sure since as I say the term doesn’t seem to have been defined. www.BRSolutions.com