In current discussions, I find people are not being careful about the difference between “event” and “business rule”. An event is something that happens. A business rule gives guidance. An event is an event and a business rule is a business rule. A business rule can produce a fact (‘automatically’) that an event has occurred. But that fact is not the same as the event or the business rule either. To see the whole picture, you need to relate 3 distinct things. The following example Illustrates. The Event …

A credit card is used to purchase something. The purchase happens in the real (or virtual) world.

The Business Rule …

A credit card event must be considered potentially fraudulent if all the following are true:

• The credit card is used to purchase a very low value item.
• The credit card is used to purchase a very high value item that is easily resellable.
• The second purchase occurs after the first purchase by less than an hour.

The Fact …

“Credit card event is potentially fraudulent.” This fact is what we know (or infer) about what happened in the real world.

These are three distinct things representing how what we know is derived from what happens in the world around us. P.S. This position represents the SBVR view.

I’ve written on this subject many times before, but let me summarize my position concisely. By the way, I expect heavy flak on the last point. See what you think. (1) Business rules should be expressed declaratively based on common business vocabulary.

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).

 

What is operational business know-how? How can you model it? What results can you achieve by doing so? The answers lie with creating true-to-life business models based on behavioral rules, decision rules, operational business decisions, and operational business events — all as first-class citizens. Understanding their intertwined roles is key to creating top-notch business solutions and business operation systems unmatched in their support for business agility and knowledge retention. Find out what ideas and techniques you need to create know-how models: http://www.brcommunity.com/b623.php

Ever suspect a high B.S. factor in the categories vendors use for their products? Wait, let me ask that differently: Has anyone not suspected a high B.S. factor in the categories vendors use for their products? I came across some older posts by Curt Monash that formalize the rules of software category B.S. I invite you to read them — good stuff. By the way, Curt Monash is an independent industry analyst I’ve greatly admired since his gutsy take-take of Cullinane some 30 years ago. [My comments in brackets.] Monash’s First Law of Commercial Semantics: Bad jargon drowns out good. “The idea behind the ‘Law’ is this:   If a term connotes some kind of goodness, marketers scarf it up and apply it to products that don’t really deserve it., making it fairly useless to the products that really do qualify for the more restrictive meaning. ‘Predictive analytics’ sounded cool, and now covers a fairly broad range of statistical analyses, most of which don’t involve any kind of explicit prediction.” [“Decision management” is already headed in the same direction … or worse.] http://www.strategicmessaging.com/monashs-first-law-of-commercial-semantics-explained/2009/01/09/ Monash’s Second Law of Commercial Semantics: Where there are ontologies, there is consulting. [Ooooh, the “O” word!] http://www.texttechnologies.com/2007/12/23/text-mining-myths-realities/ Monash’s Third Law of Commercial Semantics: No market categorization is ever precise. [This one is probably self-evident.] http://www.strategicmessaging.com/no-market-categorization-is-ever-precise/2011/03/01/ Most recently Curt invokes the Third Law for “Complex Event Processing” (CEP). He suggests that “Data Stream Management ” might be a better term. www.dbms2.com/2011/08/25/renaming-cep-or-not/ Although possibly on-target for current products and their technical orientation, I disagree with him here in the bigger picture. Events are simply a different primitive than what data represents (things). So the suggested name takes the focus off-target. Perhaps “Event Stream Management” would be better. Why does this interest me? Sooner or later, techniques and tools for business analysis need to come to grips with business events. This focus is essential for truly supporting business rules and know-how management. “Events” belong right up there with the other five primitives: things, processes, locations, roles, and goals. (Yes, there’s six — it’s a Zachman view.)