Measuring the Business Rules Approach

My last blog entry “Business Rules Approach” was eloquently critiqued by a fellow Business Rules blogger (someone I might add who appears to hold a good deal of expertise in the area of the Business Rules Approach, and Business Rules Management Systems).

Namely, The following blog entry Speeding up your projects & defeating complexity with Business Rules counters my statement that by following the Business Rules Approach it will cost you up-front, but will pay off big down the line. Namely, Rajgo argues that following the BRA will in fact also save you time up front, and cites the following reasons:

1. BRMS allows you to capture & categorize rules. So, working with large sets of rules becomes immediately easier.
2. BRMS allow you to see the rules directly, even debug them. So, mistakes will be limited
3. Once taught how to do so, a business analyst can create the rules without an underlying object model and test it, and then IT can map the business terms used in the rules to a programming model. You will make less errors this way.
4. BRMS offer many different rule formats that allow for capturing different kinds of rules (If The independent, decision tables, flow rules etc). Rules are represented in a most natural way.
5. Using a BRMS allows you to concurrently build your rules and the application. Rule development & system development can actually go in parallel.

I would have to agree with all of these points. However, my original post on the subject was squarely aimed at people who are not familiar with the Business Rules Approach, and it is their expectations I was trying to manage. Therefore, I believe that if you haven’t before attempted the Business Rules Approach, or don’t already have a Business Rules Management System in place, then as you might expect there is simply an upfront “learning curve” cost that comes with the adoption of any new technology or system. I think I’m stating the obvious here. However, over time - as Rajgo points out - the BRA can and should lead to reduced project costs.

That notwithstanding, I’m going to play “Devils Advocate” and pose the question: Has anyone done any benchmarking on the BRA from a project management perspective? I’ll likely revisit this in a future post on IT Measurement (something else that is near and dear to me), but for now I’m just throwing these two questions out there:
1. Does the BRA reduce the number of Function Points required to build a new system (my hunch is yes). And if so, by what degree?
2. Does the BRA reduce the average cost to develop a Function Point? The answer to this is less obvious to me, but I’m leaning towards thinking that it should.

If anyone has come across any information that would provide insight into the answers to these questions, please e-mail me. IT benchmarking is still a rare sight, which is one of the reasons why so many IT project estimates are often disastrously wrong.

I believe that one of the other advantages of the Business Rules Approach that I have not already mentioned, is that it leads to more consistent (and thus accurate) project estimates. After all, if an enterprise can homogenize its Business Rules within a Business Rules Management System, over time it will be able to develop metrics surrounding the creation or modification of those rules. For example, let’s say you have two teams quoting a project. The first team comes back and says:This Change Request is going to require the modification of 65 business rules, and on average a rule costs $1000 to change (based on historic tracking), we can complete the work for $65,000.

The second team comes back and says:
I had Bob look into it, and he says that it will cost $45,000 if he does the work, but something close to $80,000 if he doesn’t have time, and someone else does it. Oh, and Bob doesn’t have time to break down those costs, you just have to trust him.

Guess which team will be chosen. Managers prefer predictability over volatility.