Business Decisions and Business Rules: What’s the Difference?

Within the past ten years the business rule community has been referring increasingly to business ‘decisions’ in its books, papers and internet forums and somewhat less frequently to business ‘rules’. But what is a business decision? Is it a synonym of business rule? Some certainly seem to use it that way—some tabular rules even come in the form of ‘decision tables’.

Is ‘decision’ a new term for ‘rule’, invented to help with marketing of the same old ideas for comparatively ‘new’ disciplines like Enterprise Decision Management? Are decisions the new rules, or just hype? Or is a decision a genuinely new idea in its own right?  Are business rules and business decisions compatible: can they be used together, or must one choose between them?

This article explains our view—forged by front-line experiences over the past decade—that business decisions and rules are very different things.

Business Rules and Business Decisions: The Distinction

Introduction

Whereas once there were just Business Rules (BR), there are now also Business Decisions (BD). In 1995 vendors started to offer Business Rule Management Systems (BRMS), but, about a decade later, they also started to sell Business Decision Management Systems (BDMS). So, what’s the key distinction between rules and decisions?

How They are Alike

Business decisions and business rules share many goals. Specifically, with respect to declarative business requirements and logic, decisions aim to:

• express and visualize business logic in business terms—separately from program code or processes—in a non-technical format that supports automation;
• to allow business SMEs to understand, interact with and review business logic;
• to allow SMEs to ‘experiment’ with, test and improve them and, most importantly, to have a direct role in controlling their evolution swiftly and safely in conjunction with (rather than via) IT teams.

Both concepts are intended to improve transparency and expedite change. They are a means of ensuring that business SMEs really understand the business behaviour of their company’s operational systems. In the best case, they should allow business SMEs to experiment with their business logic without any involvement from IT at all. For those not familiar with these advantages, we discuss the business benefits of this approach in this article.

To this end, both decisions and rules support:

• The definition of business constraints: a boundary between valid and invalid ways of doing business—a judgement about whether a given operational scenario should be permitted or not. These behavioural statements define mandates or prohibitions. For example: preventing a loan of more than £10,000 being offered without an independent agent signing off, determining if an insurance application can be automatically underwritten given a set of facts about it, or validating a financial product.
• The determination of derived business information: the classification of information, or calculation of new values from existing ones that supplements or structures business knowledge. These are called structural statements. For example: determining the credit rating of a customer, classifying the loyalty rating of a customer, calculating the risk that they will have an accident, inferring the type of asset received.

Both decisions and rules have a set of inputs and a conclusion (or outcome); the former are used to derive the latter. Both use business terms and the relationships between these terms (facts) to express inputs and conclusions. Both must be capable of explaining their behaviour, after the fact, in a rationale.

How They Differ

In our view where rules and decisions differ is:

• rules and decisions have different levels of granularity: the decision is a composite package of business logic directly deliverable to the business , whereas a rule is simpler and smaller. A business rule might express how to determine the risk of a loan defaulting or select the insurance tariff to use in a specific region, whereas a business decision might determine higher level outcomes such as whether a customer loan application should be approved or whether an insurance application should be referred for manual underwriting.Decisions are dependent on a coherent hierarchy of rules (or sub-decisions) each of which support it. This structure can be expressed as a ruleflow (a sequence of rules executed with common purpose), or, much better, as a decision model (in the figure below, the decision is shown in yellow and the data it depends on in green. The relationships are shown as lines between them). Decision models are better because they lack sequence and are structured solely on logical dependencies between rules. They are a specification not an implementation.
  

  A Decision Model in DMN

  Each input of a decision is either provided as a direct data from outside, or is calculated in turn by sub-decisions that support it. Each of these supporting structural rules  has similar inferential dependencies. This network of dependencies continues until we reach a ‘leaf’ rule (like the bottom left one in the diagram), the conditions of which rely on no other rules. Decisions are composed of sets of rules in this way, but rules are not made of decisions. Rules are the atoms of business logic, decisions are the complex molecules.

• decisions are always tangible to the business  but rules may not be: decisions are strongly tangible to business subject matter experts (SMEs). They represent an operational business determination that is significant enough to be directly supportive of one or more business strategies or be mentioned directly in a business process. For example, the decision  ‘determine the accounting required for a given product’ or ‘determine the liquidity compliance of a position‘ directly impacts a business process. However, rules are smaller in scope and less tangible (at least initially). For example: the rule ‘calculate the account for a ledger entry’ or ‘determine the dominant credit rating of a position‘ is unlikely to directly impact a business process. Rather they are rules families they support coarser grain decisions. Decisions are frequently (but not always) where the analysis of business logic begins and they led to ‘top-down’ analysis.
• decisions nearly always have their effectiveness measured: a business SME would be interested in measuring the performance of a decision, because of its tangibility. This would normally be achieved by associating it with one or more business motivations (perhaps in a business motivation model) and either: measuring its performance using a relevant KPI metric for that motivation or determining if it has met a goal associated with that motivation. If the motivation is ‘decrease the manual referrals to an underwriter’ then a useful metric might be ‘the percentage of policies referred for manual underwriting’. A goal might be ‘reduce the portion of manual referrals to 15% by Q4‘. Rules deliver little intrinsic value (on their own) and their performance cannot be meaningfully measured in isolation. Furthermore, even if you could measure the effectiveness of a rule, it is unlikely to be cost effective to do so.
• decisions and rules handle exceptions differently: decisions are self-contained and must handle their own exceptional conditions—they must deliver a result, even if that result is exceptional. Rules, on the other hand, may leave some exceptions to be handled elsewhere and it is accepted that they may not be able to yield a result in all circumstances.
• decisions are visible in a service oriented architecture: business decisions are often implemented as decision services: stateless components that expose a service interface that allows clients to invoke a decision directly. These are usually widely reused by many client channels. Business rules are rarely if ever exposed at the service level because they are too fine grain and have too much context to understand in isolation.
• decisions and rules are reused in different ways: rules can contribute to many decisions by being included in the dependencies for that decision and being packaged into the decision service that delivers it. However decisions are reused by invocation—as decision services.
• decisions interface directly to business processes: unlike rules, decisions directly steer business processes—they are the means by which business expertise is injected into processes. Decisions are sufficiently important to be exposed in business process models as decision tasks (see the attached BPMN model, the decision task is the one requiring complex and volatile business logic and is denoted with the business rule symbol—a table icon).
  

  Integrating Decisions into a BPMN Business Process

  Decision tasks are tasks within a process model that make a business decision and are followed with a gateway (to allow process routing based on the outcome of that decision). These embed volatile decision logic (expressed in a decision model) allowing it to be separated from slow changing process logic (expressed in BPMN for example). This in turn promotes the agility of decision evolution and keeps decisions declarative by avoiding the sequential detail of a process model.

So, if you are working on a fragment of business logic which: requires distinct sets supporting logic to evaluate its conditions; is readily tangible to a business SME as a determination to be made during business operations; must have its effectiveness monitored; is directly referenced in the process model; handles its own exceptions; is reused only by invocation; and will be exposed as a service in the application architecture—then you have a decision. Otherwise, you are looking at a rule.

A False Distinction: Decisions Promote Autonomy of Business SMEs

Some would suggest that the key distinction between rules and decisions is that the former represent a partnership between the business SME and IT. A collaboration in which each provides a part of a rule: the SME provides semantics, requirements and business terminology and IT provides the underlying implementation in a programming language. Decisions, however, represent ‘the next phase’—they are purely the prerogative of SMEs. This view holds that there is no need for IT during the design, implementation and testing of decisions, even when these decisions are executable. IT are only needed at the end of the process, when a finished decision model needs to be integrated with a production system. This distinction between rules and decisions is often geared to a specific product offering (e.g., OpenRules-5, a BRMS, versus OpenRules-6 which is both a BRMS and a BDMS).

We are not satisfied by this definition; primarily because it it is only a process oriented distinction and specific to a particular (although very fine) implementation—a vendor product. Also, it appears to be a marketing distinction for BDMS versus BRMS and, as such, serves to differentiate product: it doesn’t really address the real distinction between the concepts themselves, but rather one of the outcomes of it. There are environments that allow rules to be developed without the involvement of IT (at least initially), so this dichotomy isn’t real either. Finally, it is inconsistent with the use of the term ‘decision’ elsewhere.

Conclusion

The distinction between rule and decision is real and important, but more subtle than you might expect. The terms are not synonyms, but informally, they are frequently used as such. They are compatible and frequently used together (you can’t have decisions without rules). Decisions are not hype or (exclusively) used as a marketing ploy; they are a genuinely useful idea. Decision Management and Decision Modeling represent significant steps forward in the maturity of documenting business requirements and logic.

If you’ve been using business rules as a vehicle for business SMEs to  express and control business logic and you’ve packaged sets of rules together to solve one overarching business problem—you’ve already been using decisions. They are served by BRMS and BDMS; the latter are a major, business-oriented refinement of the former—and very worthy of investigation because they improve the scaleability of rule repositories.

Anyone who tells you differently may be trying to sell you something.

My thanks to Jacob Feldman, Larry Goldberg and James Taylor for help with this article.