Rules as Constraints: On or By the System Design?
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 (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!
 By system in this discussion, I mean a knowledge/record-keeping system to support business requirements.
# # #
About our Contributor:
BRSolutions Professional Training Suite
All About Concepts, Policies, Rules, Decisions & Requirements
We want to share some insights with you that will positively rock your world. They will absolutely change the way you think and go about your work. We would like to give you high-leverage opportunities to add value to your initiatives, and give you innovative new techniques for developing great business solutions.
How to Define Business Terms in Plain English: A Primer
How to Use DecisionSpeak™ and Question Charts (Q-Charts™)
Decision Tables - A Primer: How to Use TableSpeak™
Tabulation of Lists in RuleSpeak®: A Primer - Using "The Following" Clause
Business Agility Manifesto
Business Rules Manifesto
Business Motivation Model
Semantics of Business Vocabulary and Business Rules