Tuesday, February 8, 2011

Business Rules Manifesto

The folks at businessrulesgroup.org have written a manifesto, entitled, conveniently enough, the "Business Rules Manifesto"

Who knew!?

Seems like everyone has a manifesto these days.

In any event, it makes interesting reading. There are ten 'articles' that more or less lay out the 'rules about "rules"'. Perhaps the articles should be called meta-rules.

Article 2 and 3 are my favorite:

Article 2. Separate From Processes, Not Contained In Them
2.1.
Rules are explicit constraints on behavior and/or provide support to behavior.
2.2.
Rules are not process and not procedure. They should not be contained in either of these.
2.3.
Rules apply across processes and procedures. There should be one cohesive body of rules, enforced consistently across all relevant areas of business activity.
Article 3. Deliberate Knowledge, Not A By-Product

3.1.
Rules build on facts, and facts build on concepts as expressed by terms.
3.2.
Terms express business concepts; facts make assertions about these concepts; rules constrain and support these facts.
3.3.
Rules must be explicit. No rule is ever assumed about any concept or fact.
3.4.
Rules are basic to what the business knows about itself -- that is, to basic business knowledge.
3.5.
Rules need to be nurtured, protected, and managed.

So let me put this in my words.

Business rules are actionable specifications of behavior that explicitly implement a policy.  The policy could address legality, ethics, responsibility, authority, or custom.

The specification has three [at least] arguments: ~condition, activity or behavior, constraint or boundary~.  Of course, there could be others: ~'date applicable', 'applies to', 'exceptions', 'inclusions', 'extensions', 'authorized by', 'appeal to'~ are examples. Constraints or boundaries are enforceable, either by system functionality or administrative procedures.  Behavior can be animate or inanimate on the part of 'actors'.

Sometimes, the arguments are arranged in an 'if-then-else' logic:
IF ~condition~, 
THEN ~activity or behavior~~boundary, constraint~, 
ELSE ~activity or behavior~~boundary, constraint~.

Too much structure?

How about this example: "No receipts are required for business expense items < $25"

Now, I use the term business to explain all this, and it probably connotes a front office or back office organization, but in fact, 'business' is the enterprise, and enterprise could include everything from a commerce activity to a weapons platform in a military context.

In this regard, project managers should engage business analysis to construct business rules as a part of any requirements definition and specification process.


Delicious
 Bookmark this on Delicious  
Are you on LinkedIn?    Share this article with your network by clicking on the link.