The Business Rules Perspective

“Business Rules” is not simply a technology, it is a fundamentally different approach to systems engineering.

Years ago, when I first heard the term “business rules,” I remember thinking that we had some up with a new buzzword meaning the same thing as what we had been calling “requirements” since COBOL crawled out of the mud.  That impression is not entirely wrong, but it does not cut to the heart of the issue.

The heart of the issue is that software developers tend to use tools that already are tied to some technology.  Database designers used ERDs (in whatever notation) to define their database objects.  UML advocates used some set of UML tools to help define parts of their object-oriented systems.  In both cases, the technology drove the design of the notation.

Even current self-proclaimed business rules tools fall into the same trap.  They assume that you have a database as well as some kind of technology and then create a grammar to describe (in mostly user-friendly terms) what some subset of the system should do. This is not really a “business rules” approach.

The business rules approach means that you do not think about technology at all. You are totally focused on the business and are trying to capture what the business does and how your system needs to behave to support it.  While capturing business rules, you should not even be thinking what database (if any) you will be using.  It should not matter whether you will ultimately be building in JavaEE, .Net, or even client/server vs. web.

The analysis people play this game pretty well, but they do not produce anything of much value.  Generating a few hundred (or even a few thousand) natural language business rules is only scratching the surface of a system description.

The problem is that there are a few hundred thousand business rules in any significant system. The issue is how to manage such a huge number of rules.  English language sentences quickly turn into unmanageably huge documents.  Formal, mathematical looking grammars generate gigantic lists of rules that are of little value for building a system.

Because of the huge number of rules there are a few obvious conclusions:

1. Natural language sentences will never work. We need something more compact and efficient.
2. We need tools that allow us to drill down to more detailed rules from a higher level.

Once we have our rules, only then do we ask what to do with them.  The articulation of the rules is independent of the physical implementation of the rules.

Tomorrow, I will discuss the rules architecture.