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:
- Declarative business rules.
- Work milestones (states through which loosely organized work still must progress).
- Automatic event identification (as in USoft).
- Event detection and management (as in Tibco).