In this one-per-month special 'notepad' series, I am taking a quick look at important issues facing practitioners who are seeking to understand and apply the business rules approach for capturing business requirements and developing business systems.

Let's work the question from a set of sample rules.  These are rules that might be captured as part of a business model (Zachman row 2) -- that is, as business requirements to be supported by a system design^[1] (Zachman row 3).

Rule:  A group must not include both union members and non-union members.

Rule:  A poor-risk customer must not place a rush order.

Rule:  An employee's new salary must be greater than or equal to the employee's current salary.

Rule:  A truck carrying hazardous material must not be routed through a downtown street.

Rule:  A trainee must not send a memo to a manager without permission of his supervisor.

Rule:  A person must be considered a woman, if the person is female and is over 21.

Do these rules represent constraints to be imposed 'on' the system design?  Perhaps the answer is yes in the general sense that all business requirements are 'constraints' on a system design, but the true sense of these rules is much more specific than that.  A more accurate view of rules is that they are constraints to be imposed by a system design.  In that sense, only a subset of all business requirements qualifies as 'rules.'

It is also accurate to say that rules are something to be imposed by the system at run time.  This implies some technology to impose them.  But how the system 'imposes' rules is a class-of-platform issue (Zachman row 4) because it presupposes a class-of-platform selection -- for example, a rule engine (declarative implementation) vs. Java or COBOL (procedural implementation), or workflow engine, scheduler, security package, etc.

The system design itself should not indicate how rules are to be tested/fired.  Not having to categorize or analyze rules according to class-of-platform issues proves to be hugely simplifying.  At that level, rules are simply rules -- no class-of-platform concerns necessary!

Notes

[1]  By system in this discussion, I mean a knowledge/record-keeping system to support business requirements.

# # #