The Implementation Business Rules Manifesto

Everyone likes manifestos.  They sound fun. They are short.  They try to distill “the core ideas.”

First, what is an “implementation rule”? Lots of people use the term “business rules,” but there are lots of different concepts that all seem to be called “business rules”.

From my perspective, there are three types of business rules:

Analysis Rules:

Analysis rules are primarily designed to help you communicate with the users. They are arguably a better way of thinking about analysis. They are expressed in natural language, or near to natural language.  They help users and IT professionals come to a mutual understanding of the scope and nature of the system.  I submit that Ron Ross refers to these types of “analysis rules” in his Manifesto (see Business Rules Concepts 4th ed. P 143).

Implementation Rules:

These are the rules that I find most interesting.  Assuming that I want to use a rules approach to build the whole system, then I need a grammar that allows me to say everything about the functionality of the system in order to completely specify that system.  Using this approach, the rules ARE the system. Implementation rules encompass the formal, complete specification of the system and can actually be used to generate the system.

Tool Rules:

These are the rules that self-proclaimed business rules products define as “the subset of implementation rules that my tool supports”.

The following is my summary of the Implementation Business Rules Manifesto:

  1. An implementation rule is a formal, complete representation of a rule that is directly implementable in the system.
  2. An implementation rule is understandable by a functional user.
  3. Determining the set of rules that describes an entire system is an art.  Functional users can assist in the process, can understand the final rule set, but cannot define all of the rules themselves without support from an IT expert.
  4. The articulation of the rules is independent of the implementation of the rules.
  5. There are thousands of rules in a system.  The key to using a business rules approach is that you need to be able to manage all of the rules.
  6. You will never be able to use business rules as a way to articulate 100% of the system.  You might get close, but there is always something that requires REAL code in your system.
  7. No single rule grammar will support all rules.  More than one kind of rule grammar will be needed.

 

Share this!
Tagged with: ,
Posted in BLOG, Business Rules, Dulcian News, What's New

Leave a Reply

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

*

Disclaimer
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.