What is the “Business Rules” approach? What is its impact on the SDLC? I was recently asked these questions by an organization contemplating moving to a rules based environment. I think that these are great questions.
First, the usual answer to switching to a rules-based approach is that “It just makes things worse.” This is because most groups adopting a business rules approach using a rules engine are not really changing the way in which they build software. They are just buying a rules engine and using it for “some” things. This means that all you have really accomplished is having YET ANOTHER place to put your business rules. Therefore, you have increased the complexity of your project.
So, for this first post on the topic, let’s start with the question: “What does it mean to use a business rules approach?”
The business rules approach to application development technically means that you are moving the whole development process up one level of abstraction. You are not building the database and writing code. Instead, you are describing what your system should do in a technology-independent way, and then generating the system.
I fundamentally disagree with some business rules approaches that can be summarized as follows:
- Capture the rules in a user-friendly way.
- Pass that rules document/repository or whatever to the developers for coding.
This process sounds to me like the same old waterfall approach with the analysis document simply being renamed.
The high level architectural description of using a business rules approach is something like the following:
1) Decide on (or build) one or more rule repositories that allow you to specify your system.
2) Capture all of your business rules and put them into the repositories.
3) Generate the system from the repositories
4) Write code for the bits that did not fit into your rules structure. Of course, this implies that the rules specification is precise enough to generate the system, so rules such as “A purchase order must go through three levels of approval” is not an implementable rule.
The next step is to create the generators. You may be using a product where the generators already exist. It is highly possible that they don’t generate exactly what you want. Maybe you need to tweak the generators to achieve the desired results. You may need to extend one or more of the repositories to handle things that you need to say about your system, but the repositories don’t support these extensions. You may even need write a whole new repository and generator to deal with a new kind of rule that you have never encountered before.
Finally, you are ready to generate the system from the repositories. You should NOT then modify the generated “stuff” (database objects, code, or whatever). The rules in the repositories are the whole system… mostly. There is always some amount of code that you have to write that does not fit into your rules structures.
The goal is to minimize the amount of hand coding you have to do. Using the approach outlined here, we are consistently able to keep the amount of hand coding to <5% of the total. For example if, in a particular system, the generators generated 1 million lines of code, some developer would have to write < 50,000 lines prior to generating and putting the system into production.
Leave a Reply