Experience has shown that sets of business rules, even those administered using Business Rule Management Systems (BRMS), become very hard to manage and understand once they reach a certain level of size and complexity. Although small, very tightly focused rule sets can be effective for simple business domains, large rule sets are challenging to create and even harder to maintain. Small rule sets that become large over time (scale up) present the most difficulty. They are at risk of collapsing under the weight of their own growing complexity or becoming the sole preserve of a small number of ‘gurus’ and ‘high priests’ who alone understand them—defeating a key objective of business rules.

In a previous article, I described how to overcome the challenges of maintaining a business rules over a long period. But how can you manage the complications of rapidly growing rule sets: keeping them easy to understand, changing them safely without unintended consequences  and avoiding ‘stale’ and duplicate rules? Here we show, by example, how Decision Modeling, used from the outset can address all these problems and we discuss in more detail the difference between business decisions and business rules.

Why are Business Rules Hard to Scale?

Why are large business rule sets—those that start large and especially those that become large over time—hard to manage? Why do they often collapse under their own weight, becoming a nightmare of unreliability and an incomprehensible tangle of poorly understood rules? Normally there are four main problems:

• The ‘Rush to Detail’: business rule development encourages policy makers to focus on rule implementation prematurely, before they have considered the broader goals and structure of their business decisions and to what extent they will be automated. This approach is like starting to build a house by laying bricks, rather than drawing plans and establishing foundations.
• Poor Dependency Management: a growing and poorly understood set of inter-dependencies between rules causing changes to have unintended consequences—making the rule set brittle and reducing its agility.
• Insufficient Transparency: the bewildering size of a rule set, use of technical (rather than business) terms and style for expressing rules and a poor connection between rules and their business context (their rationale and place in the business process)—making the meaning and motivation of rules more obscure.
• Lack of Growth Management: poor discipline about the scope, quality and placement of rules that are added to the rule set—making it hard to find rules and leading to ‘stale’ rules and duplicates.

All of these problems arise for the same two reasons.

Lack of High Level Organization in BRMS Rule Sets

Most rule sets lack a strong structuring mechanism above and beyond business rules and the vocabulary they require. Rule sets are literally a ‘bag of rules.’ Business Rule Management Systems (BRMS) products do attempt to provide some structuring mechanism, for example:

• Folder Hierarchy: rules are placed within a hierarchy of directories for ease of reference and to denote a classification of purpose; much like files in an operating system are organized among folders to indicate their purpose. Frequently BRMSs only allow each rule to be resident in one folder. This imposes a single classification scheme on rules and some BRMSs allow a single rule to be reused in multiple folders.
• Tag Hierarchy: rules have a series of ‘hashtags’ which allow them to be classified. The hashtag classification scheme is better than folders because a rule can be labelled with multiple hashtags and therefore appear in multiple classifications schemes.
• Decision Services: similar to the above, rules are grouped according to the decision services into which they will be deployed. A decision service is an executable, architectural component—a means of packaging the logic of one or more rules and delivering it to a consumer as part of a service oriented architecture (SOA). This functional alignment can be very useful for maintaining traceability between services and the rules that dictate their behaviour.
• Execution Sequence (Ruleflow): this depicts the order in which rules are executed. This is a means of optimization and control and works rather poorly as an organizing concept.

While these structural concepts may help to organize rules they don’t address any of the problems raised above. This is because all of these classification schemes are entirely imposed by rule authors and don’t represent inherent relationships between the rules themselves.

These mechanisms cannot be used to develop a rule set ‘top down’ driven by business need rather than ‘bottom-up’ driven by detailed rule implementation.

Lack of Connectivity Between Rules and the Business Context

BRMS often cannot support any strong relationships between rules and other artifacts that clarify their business context. For example:

• Business Process: showing when rules are used and how their outcome controls further behaviour
• Business Motivation: showing the business goals and drivers rule support
• KPI: showing the metrics used to measure rule performance
• Knowledge Sources: policies, mandates and laws to which they must conform

How Decision Modeling Addresses These Issues

A decision is a determination that produces an outcome given one or more data inputs. It isn’t the exactly same as a business rule (the distinction is explained here) but the logic of decisions can be implemented as a Decision Table, Decision Tree, rule text or other artifact supported by a BRMS. Decision Modeling is a technique for representing business decisions in a precise, standardized format that:

• Focuses on decision requirements first: development focuses first on what business decisions need to be made, their context within a business process and what they require to work effectively. This focus on requirement, and not rule implementation, allows gaps and issues to be discovered early before effort is invested.
• Documents dependencies diagrammatically: the dependencies of decisions (high level rules) on sub-decisions (subordinate business rules), input data and knowledge sources are illustrated in a graphical view (The Decision Requirements Diagram, DRD, an example of which follows)—making it easy to see how rules rely on each other and to determine the consequences of any change;
• Supports a precise representation of business logic: The Decision Logic Level of a Decision Model describes the business logic of a decision in a variety of precise, business oriented ways. Many of which have representations defined by the decision modeling standard (including Decision Tables, text and analytic models). However, for any decision this logic definition can be replaced with a BRMS artifact that implements that decision. This means every decision rectangle in a DRD can refer to a rule artifact in a BRMS.
• Succinctly defines business services: sets of cooperating decisions can be deployed together in a decision service. Decision models can represent these in terms of their interface, the rules they encapsulate and the data dependencies they have including the outcome of other decisions.

Concise Documentation of Dependencies

Decision Models can document the relationships between decisions (and therefore BRMS artifacts) using a standard notation (for illustration we are using DMN). For example consider this Decision Requirement Diagram (DRD) below. We have colored this diagram for ease of reference. DMN diagrams normally have no color, their components are recognized by shape alone.

For clarity, decisions are represented as yellow rectangles, knowledge sources (e.g., policies, mandates, personal expertise, laws) as blue rectangles with wavy undersides and data inputs as green rounded rectangles. The lines between them represent dependencies with the line symbol depicting the dependent end. An arrow depicts the dependent requires data whereas a circle depicts a requirement of knowledge (from say a policy document). Decision Requirement Diagrams can depict the hierarchy of dependencies between rules and can be scaled up easily.

This diagram tells us that the decision Determine Personal Credit Rating requires data from two inputs (Persons Debt Record and Persons Annual Salary), data from a subordinate rule Determine Persons Employment Record and knowledge from the Risk Management Policy knowledge source. The latter indicates that this policy acts as an authority in the definition of the business rule Determine Personal Credit Rating.

Because DRDs force us to consider, at the outset, the needs of every business decision and their alignment to business processes and motivations they save a great deal of time lost to false implementations.

Transparent Definition of Business Logic

Every rectangle in the DRD represents a decision which can have a logic definition. Decision models have a standard way of representing the logic of rules and DMN is no exception. If we represented Determine Personal Credit Rating as a Decision Table rule in DMN it might look like this (I’ve added labels for clarity).

All decision logic must be consistent with the dependencies documented in the DRD. Therefore all the data required by the Decision Table’s conditions (Persons Employment Record, Persons Total Debt and Persons Annual Salary) are supplied in the data requirements of the DRD, above. Similarly, the conclusion of this table, Personal Credit Rating, is the data required of the Determine Personal Credit Rating decision by its parent decision Determine Personal Loan Limit. The DRD acts like a ‘summary’ of the data dependencies between rules.

More importantly, because the logic of each decision can forgo representation in DMN and be represented as a rule artifact in a BRMS, the DRD can act as the summary (a road map) of an entire ruleset.

Imagine the power this would give to the user of a BRMS: if each of the rectangles in a DRD represents a business rule, this gives us a visual display of rule dependencies. Decision model DRDs become a formal, high level structure for a rule set. Furthermore, each decision (rule) can be reused in many DRDs and, because of their hierarchical structure, they can scale arbitrarily.

Definition of a Decision Service

DMN can also define a graphical representation of a decision service—a capability not offered by most BRMSs. This is depicted in the DRD as a white rounded rectangle with two compartments. All decisions within this rectangle represent rules deployed as part of the decision service. The rules depicted in the top compartment determine the public interface of the service

(the conclusion(s) of these decisions represent the outcome of the service). The decisions in the lower compartment are private: they can be used by the public decisions (to satisfy their data requirements) but cannot be seen by decision services users. The data and decision components outside the rounded rectangle represent the needs the service has of the invoker: what data must be provided to user the service.

The decision service shown determines the Personal Loan Limit of the individual when provided with their Employment History, their Employment Record, their Annual Salary, their Debt Record and the Clerk Record of the loan assessor. We will not cover here how the decision model is aware of the relationships between these items.

Benefits of Decision Modeling Your Business Rule Set

In short, but augmenting a rule set with its decision model, you can:

• Encourage the development of rules sets to be more focused on the definition and requirements of business decisions—saving time and ensuring alignment to business goals.
• Focus on business not technical representations—making rules simpler to understand and identifying what artifacts need to change as business needs evolve.
• Use DRDs to represent the ‘high level’ (roadmap) structure of a rule set right from the beginning—help users to understand how rules collaborate to determine an overall outcome and how any given rule can be decomposed into subordinates.
• Use DRDs to achieve a visual depiction of how decision services are defined.
• See at a glance the dependencies between all rules and understand the impact of changing a rule or data input (business vocabulary item).
• By establishing rule traceability with business process models, data models, business motivation models and regulatory, policy or legal frameworks (i.e. knowledge sources) one can increase the transparency of the business context and rationale of each rule in a rule set.

The visual depiction of DRDs also helps to:

• Make the rule set more accessible to business users by offering a view that elides technical detail and is designed to be used by business analysts.Scale the rule sets to larger sizes without confusion.
• Allow gaps to be discovered quickly. For example, it provides immediate visual indication if a rule becomes obsolete (because it has neither dependents nor services).
• See patterns of dependency that could be harmful before they take root (e.g., lots of dependencies on a single, volatile rule or data item).
• Offer a means of designing new decision services and rule sets ‘top-down’ instead of ‘jumping to detail’ with individual rules.
• Help those looking for an existing rule or the most appropriate place to fit a new rule to offer a desired flexibility.

Bottom Line

In short, improving the scalability, business alignment and robustness of business rule sets is just one of the beneficial applications of decision modeling that can save time and ensure the life expectancy of rule sets is enhanced.

If you are interested in this or other benefits of decision modeling please feel free to contact us or consult our new book on DMN.