Sample behavioral business rule: A customer that has placed an order must have an assigned agent. A practitioner wrote: In process design this means that an activity ‘Assign agent’ must happen before an activity ‘Take order’. My analysis: Here’s how behavioral business rules like this one should work according to standards[1]:

• If the business rule is violated in performance of the process ‘Take order’, then the process (activity) ‘Assign agent’ should be (optionally) invoked automatically so the violation can be corrected immediately (by the appropriate actor).
• In performance of the process ‘Retire agent’ (which hasn’t been mentioned!), if the business rule is violated – i.e., the retiring agent is assigned to some customer who would thereby be left agent-less – the process (activity) ‘Assign agent’ should be (optionally) invoked automatically so the violation can be corrected immediately (by the appropriate actor).

There’s one business rule, but two kinds of events (in separate processes) where the rule can be violated. I’ve literally looked at 10,000s of business rules. Probably 95% or more are multi-event like this, and therefore often multi-process. You can see from this example how easy it is for business analysts to completely miss the second event. My contention is that’s one big reason why systems today often give such inconsistent results – the other event(s) are overlooked or in another process altogether. Conclusions

• It’s highly misleading to say ‘business rules are part of processes’. No, not really. (I run into that statement all the time.)
• We’re not designing processes today in a very intelligent way. Designers shouldn’t have to think, ‘O.K., which process (activity) has to come first because of the business rules?’. That approach forces us into sequences where no natural sequence is meaningful. In any case there are far too many behavioral business rules for it to be practical.

P.S. If you think ‘decisions’ will fix this fundamental problem, sorry, but I’m afraid you’re in for a rude awakening! ~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4^th ed, 2013), by Ronald G. Ross, 162 pp, http://www.brsolutions.com/b_concepts.php For me the point of knowledge (POK) is a real place.  POK is where elements of operational business know-how — business rules — are developed, applied, assessed, re-used, and ultimately retired.  In other words, POK is where business rules happen.  Knowledge is power, so  you can also think about POK as point of empowerment. POK corresponds to point of sale (POS) in the world of commerce.  POK and POS are similar in several ways:

• In both, something is exchanged.  In POS, it’s goods.  In POK, it’s operational business know-how (from here on I’ll just say know-how).
• In the world of commerce, we often say that consumer and supplier are parties in point-of-sale events.  Each of us is a consumer in some point-of-sale events, and many of us act as suppliers in others.  The same is true for POK.  Each of us is a consumer of know-how in some POK events, and many of us act as suppliers in others.  Sometimes we switch roles within minutes or even seconds.
• A well-engineered experience at the point of sale has obvious benefits both for the consumer — a positive buying experience — and for the business of the supplier — real-time intelligence about sales volume, cash flow, buying trends, inventory depletion, consumer profiles, etc.  A well-engineered experience at the POK likewise has obvious benefits.  For the consumer, it means a positive learning experience.  For the business of the supplier, the benefits include real-time intelligence about the ‘hit’ rate of business rules, patterns of evolving consumer (and supplier) behavior, emergence of compliance risks, etc.

The consumer/supplier experience at  the POK is crucial to worker productivity and job satisfaction.  In no small measure, optimizing this experience is the real challenge in POK engineering.  It must  be deliberate.  After all, what’s exchanged  at the POK is know-how — something you can’t carry around in your hands. Today, much of your know-how is tacit — lose the people, you lose the know-how they carry in their heads.  How can you avoid that?  Make the know-how explicit as business rules.  That’s what POK are about. Critical success factors in engineering an effective POK include:

• Communication must be strictly in the language of the business, not IT.
• Interaction must be gauged to the knowledge level (and authorization) of each individual party.
• Less-experienced parties playing the consumer role must be enabled to perform as closely as possible to the level of the company’s most experienced workers.
• Know-how — business rules — must be presented and applied in a succinct, highly-selective fashion.
• Know-how — business rules — must be presented and applied in a timely fashion (i.e., ‘just-in-time’) to accommodate fast-paced refinement and change in business policies and practices.

Consider the following example.

Behavioral Rule: A student with a failing grade must not be an active member of a sports team.

This business rule:    

• Is not about selecting the most appropriate sports team for a student – i.e., not about the decision, Which sport team is best for a student?.
• Does not apply only at a single point of determination – e.g., when a student joins a team.

Instead, the business rule is meant to be enforced continuously – for example, if a student who is already active on some sports team should let his or her grades fall. What’s the business decision for when a student’s grades fall and they should be taken off a team? Be real, there’s no good answer to that question. This example is no outlier. Businesses have 1,000s of behavioral rules like this. Let’s be clear – I believe a business-decision-based approach is very powerful for decision rules. I have written much about that. And I don’t disagree that many business-rule projects have floundered due to lack of pragmatic organizing principles (e.g., “decisions”). But if you take a decision approach to behavioral business rules, either it will prove woefully incomplete with respect to integrity, or you’ll quickly start to drown in (system-level) decisions. In my opinion, an application that has to be designed and to operate to treat violations of behavioral rules as just more decisions is not a smart enough system. The detection of violation events for behavioral rules can be, and should be, completely under the covers (identified, detected and supported by a platform). Otherwise the solution won’t scale. And there will be so many decision dependencies it will steal from the very real value of a business-decision-based approach. This frankly is a sign of immaturity … or lack of imaginative leadership … or IT bias … or whatever … in some parts of the decision-model community. The detection of a violation of a behavioral rule is an event, not a decision. A business decision is a business decision; a system decision is … well … why even go there?! P.S. There are 3 specific examples and more complete discussion about this topic on http://goo.gl/NCnLi.      

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

 

Each business rule usually produces multiple flash points.  Don’t know what a flash point is? I think you should! See a brief explanation: http://goo.gl/pl9sT. Why is this insight so important?  The two or more events where any given business rule needs to be evaluated are almost certain to occur within at least two, and possibly many, different processes, procedures, or use cases.  Yet for all these different processes, procedures, and use cases there is only a single business rule. Now ask yourself this (the very big question): 

What in your current IT requirements methodology ensures you will get consistent results for each business rule across all these processes, procedures, and use cases?

Unfortunately, the answer today is almost always nothing.  In the past, business rules have seldom been treated as a first-class citizen.  No wonder legacy systems often act in such unexpected and inconsistent ways(!).  Organizations today need business operation systems where business governance, not simply information, is the central concern. Business rules should be seen as one of the starting points for creating system models – not something designers eventually work down to in use cases.  That’s the tail wagging the dog. By unifying each business rule (single-sourcing), and faithfully supporting all its flash points wherever they occur, Business Analysts can ensure consistent results across all processes, procedures, and use cases.  Is there really any other way?! ~~~~~~~~~~~~~~~~~~~ Excerpted from Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA^® Sponsored Handbook, Business Rule Solutions, LLC, 2011, 304 pp,http://www.brsolutions.com/bbs  

Celebrating the 10^th Anniversary of the Business Rules Manifesto^[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #9 Question: What does principle 6.5 of the Manifesto mean?

The relationship between events and rules is generally many-to-many.

Business rules generally apply at various points in time.  Each of the various points in time when a behavioral rule needs to be evaluated represents an operational business event.    Such events can arise in either business processes or ad hoc business activity. How do you find these operational business events?  Consider the behavioral rule:  A customer must be assigned to an agent if the customer has placed an order.   Figure 1 shows the relevant terms and wordings for this business rule. Figure 1.  Terms and Wordings for the  Agent-Assignment Business Rule   The business rule has been expressed in declarative manner.  This means, in part, that it does not indicate any particular process, procedure, or other means to enforce or apply it.  It is simply a business rule – nothing more, nothing less. The business rule makes no reference to any event where it potentially could be violated or needs to be evaluated.  The business rule does not say, for example, “When a customer places an order, then ….” This observation is extremely important for the following reason.  “When a customer places an order” is not the only event when the business rule could potentially be violated and therefore needs to be evaluated. Actually, there is another event when this business rule could be violated:  “When an agent leaves our company….”  The business rule needs to be evaluated when this event occurs too since the event could pose a violation under the following circumstances:  (a) The agent is assigned to a customer, and (b) that customer has placed at least one order. In other words, the business rule could potentially be violated during two quite distinct kinds of operational business event.  The first – “When a customer places an order …” – is rather obvious.  The second – “When an agent leaves our company …” – might be much less so.  Both events are nonetheless important because either could produce a violation of the business rule. This example is not atypical or unusual in any way.  In general, every business rule producestwo or more kinds of operational business events where it could potentially be violated or needs to be evaluated.  (I mean produces here in the sense of can be analyzed to discover.) These operational business events can be called the business rule’s flash points.  Business rules do exist that are specific to an individual event, but they represent a small minority. Two additional points:

• Expressing each business rule in declarative form helps ensure none of its flash points is exempted inadvertently.
• Discovering and analyzing flash points for business rules can also prove useful in validating business rules with business people.  Important (and sometimes surprising) business policy questions often crop up. 

~~~~~~~~~~~~~~~~~~~ Excerpted from Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA^® Sponsored Handbook, Business Rule Solutions, LLC, 2011, 304 pp,http://www.brsolutions.com/bbs

In football, when a referee throws a flag, the results of the most recent transform (play) are undone. In effect, by enforcing a rule, the referee prevents or negates the new state (yardline and sometimes the down) and enforces some other state. That’s the way behavioral business rules[1] work. Speed through a school zone and see if your desired state isn’t modified if some policeman happens to be watching. The relationship between behavioral rules and business processes is an indirect one, through state. Business tasks try to produce new states; behavioral rules step in to modify or prevent the new state if a violation occurs … just like the policeman parked in the school zone with a radar gun. More precisely, business tasks precipitate events that try to change state (the outputs, final or interim), and behavioral rules ‘watch’ for the particular events that produce violations. A violation produces a response, which can be another process – e.g., the referee jumping in to whistle the play dead or the policeman putting down his doughnut and chasing you. Yes, it’s important know which business tasks can violate which behavioral rules, but their relationship more complexly networked than you might think. In general, every behavioral rule expressed declaratively can be analyzed to produce two or more events (I call them flash points) where it can be violated and needs to be evaluated. I can provide endless examples. (Refer to http://www.brcommunity.com/b623.php?zoom_highlight=flash+point or to Chapter 8 of Business Rule Concepts, 3^rd ed.) These events are likely to be in different business processes (or procedures or use cases) … and sometimes a given process may not have been modeled at all (or the event occurs ‘spontaneously’). The fact that each behavioral business rule can be violated at two or more flash points is a fundamental insight of the business rule approach. It’s precisely where current platforms, tools and methodologies fall short, and why consistency and compliance are so difficult to achieve. In other words, it’s an essential idea in really ‘getting’ business rules.

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