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.

Share this!
Tagged with: , ,
Posted in BLOG, Consulting, Development
0 comments on “The Business Rules Perspective
2 Pings/Trackbacks for "The Business Rules Perspective"
  1. […] there is a good question.  How do you explain business rules in such a way that a seven year old can get […]

  2. Why is Chronic Care Management Important? | says:

    […] organization create a cost-effective implementation of Chronic Care Management (CCM). Using our business rules approach, we can turn complex regulations and guidelines into flexible, user-friendly software to […]

Leave a Reply

Your email address will not be published. Required fields are marked *


The information presented on this blog is presented to provide general technical information. If, while attempting to apply any of the ideas, procedures, or suggestions herein, you experience any kind of programming or system problems or failure, it will be as a result of your own actions. Dulcian, Inc. and all authors of text found anywhere on this site, and all internally-linked Web sites, Mail Lists, Blogs and/or e-mail group discussion, disclaim responsibility for any user's actions and any damage that may occur based on information found on this website and associated Mail Lists, Blogs and/or e-mail group discussion. Any technical advice or directions found on or through this site is provided AS IS and its provided without warranty or any guarantee of its accuracy. You perform any modifications to programs or software AT YOUR OWN RISK.