Business Rules and the "Flow"
Correcting Some Misconceptions about Business Rules
Not long ago, I received an e-mail from an IT professional. The e-mail contained serious misconceptions about business rules. These misconceptions go to the heart of the distinction between declarative versus procedural specifications (that is, "know" versus "flow"), in particular concerning sequence. First I reproduce the original e-mail in full, then I give my point-by-point responses.
Subject: Business Rules versus Sequence
The IT professional wrote . . .
The Ross approach to business rules . . . tends to classify business rules based on a bias toward coercing perfectly good imperative constructs into less comfortable declarative ones. Ross loses sight of the need for appropriate behavioral language in favor of a misguided attempt at a purely structural expression of a business system. For example, steps in a cake recipe might be simply . . .
Combine flour, water, milk, and eggs in a large bowl.
Mix until batter is consistent but not entirely free of lumps.
Instead, Ross would prefer . . .
- Batter is mixed.
- Flour, water, milk, and eggs are combined.
- Flour, water, milk, and eggs are ingredients.
- After mixing, ingredients become batter.
- Batter must be in a bowl.
- Batter must be consistent but must retain lumps.
- Mixing batter is performed after combining ingredients.
Ross abhors sequence. Sequence is to be asserted by means of elaborate nets of [specially typed rules]. This adds nothing to the maintainability or expressive power of a business system"'s definition. We already have a perfectly natural and convenient means of expressing sequence: an ordered list.
My response . . .
>Ross abhors sequence.
>>>Absolutely dead wrong! Some of the most effective and pragmatic work in the business rule community has been done in the areas of workflow models (the business view of work) and procedures or scripts (the system view of work).
>>>We use rules (defined independently) to control the work. This is why the NFL has a rule book that is separate from the teams"' play books. That"'s because today you might be running one set of plays, but tomorrow you will probably be running another. To use your analogy, today you might be making a cake, but tomorrow you might be making a pie.
> 1. Combine flour, water, milk, and eggs in a large bowl.
> 2. Mix until batter is consistent but not entirely free of lumps.
>>>This recipe represents a perfectly acceptable (albeit very simple) procedure or script. I have no problem with it. Now let"'s ask, what rules do we need?
Potential rules to provide appropriate control might include the following . . .
Milk must be fresh.
Bowl must be large enough so that contents do not spill out when stirred.
Batter may be considered "entirely free of lumps" only if there are no visible masses of congealed batter larger than 2 cm in diameter.
>>>These rules represent business knowledge that must be present when the procedure or script is performed. All work requires guidance and/or controlÑ such guidance and control is what business rules are about. The business rule approach simply says not to embed these rules in the procedure or script directly.
>Instead, Ross would prefer:
> • Batter is mixed.
> • Flour, water, milk, and eggs are combined.
> • Flour, water, milk, and eggs are ingredients.
> • After mixing, ingredients become batter.
> • Batter must be in a bowl.
> • Batter must be consistent but must retain lumps.
> • Mixing batter is performed after combining ingredients.
>>> No! I want both a script to follow (your two-step recipe will do) and rules to guide me in doing the work. But most importantly, I want the script and the rules to be separate. So what you say I prefer above is actually the exact opposite of what I wantÑyou"'ve embedded the rules in the procedure. We do agree on one thing, however. The result is really messy!