Best Practices

In a book entitled Finite and Infinite Games in 1986, James P. Carse wrote "Finite players play within the rules, infinite players play with the rules." We play finite games every day, from checkers and chess to Yatzee and Monopoly. Finite games have a familiar pattern: a beginning, a middle, and an end; a winner and a loser.

A finite game is easy to play because it has a limited set of fixed parameters. Carse also wrote "Finite players play to win, infinite players play to keep playing." Custom software development is not a finite game, and the clients who purchase it are not finite players. The objective of a workflow application is not to win an office betting pool, or even to design and complete a superior workflow application. The objective of a workflow application is to continue to distribute an ever-changing flow of work. Yet as custom software developers we tend to play the infinite game with finite rules.

We shouldn't be taking a request from a client to change the way our application determines how work is distributed (15-day expiration instead of 30-day expiration, apply special notices to tasks above or below a particular dollar value which is later changed, etc). Instead we should be providing our clients with the tools to change these business rules themselves, so that instead of constantly trying to keep up with the stream of client change requests that result from hard-coded business logic, we can move on to the next feature or application, and play the infinite game on their terms, playing with the rules rather than playing within them.

A Brief Example
A typical business rule should be familiar to all of us and is usually described to us by a client with words like this: "commissions for this project are due to the sales person 15 days after receipt of at least 10 percent of the deposit." This rule has one objective (indicating current payments due to the sales staff) and several parameters, including the required deposit amount, an arbitrary figure (10%), the date on which the figure is satisfied, an arbitrary duration (15 days), and by implication, the current date. These are typical logical equations and we know intuitively how to write software to perform these comparisons. The code usually looks something like this:

<cfif sale.getDepositPaidByDate(dateAdd("d",-15,now()))
  gte (0.1 * sale.getFullDepositAmount())>

As long as the application you're writing will be sold only to one client, and that client never changes their rules, this line of code will survive the lifespan of our application. The problem with this is that, while it may satisfy the client it doesn't help us much. It doesn't allow us to sell the same application to another client without reinventing this portion of the code and so at the end of the day it amounts to being paid an hourly wage for your work instead of building equity in your software.

The Challenge
There are two barriers to transforming this finite equation into a flexible rule that many of your clients can modify without your aid or intervention:

1. Storage: Because the arbitrary rule criteria must become data that can be dynamically interpreted, the application will need a place to store rules of many disparate types with indeterminate numbers and types of parameters.
2. Interpretation: Once the storage of the rule data is accommodated, the application needs a system of managing and interpreting a vast array of indeterminate and ever-changing criteria to be applied to an indeterminate, ever expanding set of contexts.

You might notice in the wording of these barriers that I've used a lot of words like "indeterminate" and "expanding" and "changing." In order for your rule-management engine to provide maximum equity it needs to be designed with a minimum of assumptions about your clients' business model. Q. How many types of rules will there be? A. Unknown. Q. How many criteria will an individual rule have? A. Unknown. Q. In what type and how many contexts will the rules be applied? A. Unknown. Because there are so many unknowns it is necessary to use the most encapsulated and extensible tools available to store and to interpret the rules. To meet this challenge I choose Extensible Markup Language (XML) and ColdFusion Components (CFCs).

A single "RuleManager" CFC manages all interactions with the rule data in this application. In Object Oriented (OO) lingo this is known as a Façade pattern, in which a larger library of code is simplified by a single unified interface. Although the RuleManager will require a minimal set of assumptions, certain assumptions must be made in its design to ensure portability:

Rules are stored in XML packets; each packet may contain zero or more individual rules:

1. Each rule may contain zero or more individual criteria (nodes) of different types (date, numeric, money, text, etc.)
2. A separate CFC must be written for each type of criteria that the RuleManager will interpret (date, numeric, text, etc.) - these criteria-type CFCs must share a common set of methods (interface)
3. All parameters used by criteria-type CFCs in the evaluation of a rule must be provided in the criteria XML node or by an external context (CFC)

When tested for applicability each rule must evaluate to a Boolean value (true/false)

The criteria for a rule are cumulative, requiring the satisfaction of all criteria to apply the rule (logical and)

A mechanism must be provided for the user to establish sub-sets of criteria that are not cumulative (logical or)