When the Business Rules Manifesto^[1] was published in 2003, I co-proposed the six items below related to business processes as an additional (eleventh) Article.  The Business Rules Group (BRG) decided (probably wisely) to avoid that potentially-controversial area, however, and concentrate on the core message of business rules.

Since a Business Process Manifesto has been in the works, it's worth going back over the proposed items.  I believe they remain valid.  So I dug them out of my Editor archives, cleaned them up a bit, and present them below.

Aside:  In 2003 the BRG wasn't careful about saying "business rule" (instead of just "rule") and business process (instead of just "process").  But that's what we meant — real-world rule and real-world process — not technical specifications.  I'm very careful about that clarification these days.  A great many people have a hard time seeing the difference.

Item 1.  Business rules guide business processes.

Comment:  If this one is not self-evident, all bets are off.

Item 2.  Business rules should be substituted for any activity in a business process where the result(s) of that activity can be produced by the business rules.

Comment:  This item refers to what SBVR^[2] calls definitional rules — business rules that can derive, classify, or compute something.  For any given 'something', there might be only a single business rule, or a very large number of business rules.  The 'something' could be an operational business decision requiring many dozens or hundreds of decision rules organized into decision tables.

One thing the item doesn't say is that not all such 'somethings' need to be supported by business rules from the very beginning.  In fact as Item 8.5 of the Business Rules Manifesto says, they don't need to be.  Business rules are very good for incremental development.  (Development of what?  Smart business processes.)

Item 3.  Business rules can cause business processes to be initiated under appropriate circumstances.

Comment:  Circumstances can arise that require the business to respond in a pre-scripted manner — e.g., low inventory status, potential fraud, or intrusion, etc.  Some business rule(s) should identify the circumstances involved in such 'spontaneous' business events.

Item 4.  The default explanation or message for any error that occurs in a business process for a business reason is a business rule.

Comment:  This item is truly ground-breaking.  Business rules express the DOs and DON'Ts of business activity; therefore, any error that occurs under a business process for a business reason is 'explained' by a business rule.  What else could it be?!

Keeping systems carefully aside, and noting the obvious possibility of providing additional or alternative 'explanations', I like to say "the business rules are the error messages."  By the way, I've been saying that since 1994 — I have the slides (transparencies, actually) to prove it.  If you have doubts about this item, please provide examples(!).

Item 5.  Any delay in the ability to enforce a business rule must be coordinated with business processes.

Comment:  In SBVR, behavioral rules are business rules that can be violated.  (Definitional rules can't be.)  An example where such delay might occur is a business rule that requires an approval or sign-off on something (e.g., an extra-large order on credit) by somebody (e.g., the branch manager) who is not immediately available.  The business process for that particular something must be suspended until some future time.

Note:  Additional business rule(s) providing appropriate suspense criteria (e.g., 24 hours) would be wise in such cases.  We don't want an order sitting in limbo forever(!).

Item 6.  Business rules cannot constrain the workings of a business process directly, but only the following:  (a) the state required for the business process to be performed; (b) the state while the business process is being performed; and (c) the results — that is, the state — the business process seeks to leave behind when finished.

Comment:  I think of a business process as being like a black box with respect to business rules.  The business rules cannot and should not 'look' inside.  Instead, all matters of state should be externalized so business rules — and business people — can know it and talk about it.  Get ready for this:  This item indicts BPMN with its token-based approach to process state.  The future lies with externalizing semantics.  Sorry guys!

References

[1]  Business Rules Group, Ronald G. Ross, ed., Business Rules Manifesto ~ The Principles of Rule Independence (Ver. 2), The Business Rules Group (2003).  Updated Nov. 1, 2003.  PDF available at http://www.BusinessRulesGroup.org

[2]  Semantics of Business Vocabulary and Business Rules (SBVR), v1.0.  Object Management Group (Jan. 2008).  Available at http://www.omg.org/spec/SBVR/1.0/PDF

# # #