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 4^th 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.