An implication for business rules: No direct invocation of functions.(2) No reference whatsoever should be made to events in expressing business rules.
Exception: Some business rules (a small minority) truly apply only at the time a given business event occurs. Example: A hotel guest must be given fresh cookies upon check-in.(3) Behavioral rules (unlike decision rules) should always be evaluated immediately when any relevant event occurs. Such ability supports real-time compliance. (Read about behavioral rules vs. decision rules on http://www.brcommunity.com/b623.php.)
One Implication: You have to know what those relevant events are.(4) The events to which a declarative rule applies can (and should) be determined automatically.
USoft proved the principle 20 years ago. SBVR’s treatment of business rules is based on the assumption.(5) It’s important to determine the events automatically for behavioral rules because that way you can take programmers out of the business of event detection and management.
The benefits of doing so would be immense.(6) Events bear a direct relationship to business rules in the sense that behavioral rules need to be invoked automatically when events occur.
How else can you achieve comprehensive consistency of behavior?!(7) Business rules bear no such direct relationship to processes.
Do we really want programmers and designers to remain in the business of event detection and management forever?! In my opinion that’s a very bad idea.(8) Some (many?) business capabilities (e.g., highly social ‘processes’) could be modeled and run without business process models altogether.
How would it work? You need:
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 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 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 do’s 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!