|By Isaac Dealey||
|August 9, 2005 04:00 PM EDT||
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:
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.
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:
- 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.
- 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.
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:
- Each rule may contain zero or more individual criteria (nodes) of different types (date, numeric, money, text, etc.)
- 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)
- 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)
- Where Are RIA Technologies Headed in 2008?
- The Next Programming Models, RIAs and Composite Applications
- AJAX World RIA Conference & Expo Kicks Off in New York City
- Constructing an Application with Flash Forms from the Ground Up
- Building a Zip Code Proximity Search with ColdFusion
- Personal Branding Checklist
- CFEclipse: The Developer's IDE, Eclipse For ColdFusion
- Has the Technology Bounceback Begun?
- Adobe Flex 2: Advanced DataGrid
- i-Technology Viewpoint: We Need Not More Frameworks, But Better Programmers
- Web Services Using ColdFusion and Apache CXF
- Passing Parameters to Flex That Works