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 Let me use an example to sketch the workings of business rules in smart architecture based on points of knowledge[1].  Refer to the Figure to visualize how the system works.

Aside: I have been using this same slide since 1994(!).

Suppose you have a process or procedure that can be performed to take a customer order.

• An order is received.  Some kind of event occurs in the system.  It doesn’t really matter too much what kind of event this is; let’s just say the system becomes aware of the new order.
• The event is a flash point — one or more business rules pertain to it.  One is:  A customer that has placed an order must have an assigned agent.
• We want real-time compliance with business policy, so this business rule is evaluated immediately for the order.  Again, it doesn’t much matter what component in the system does this evaluation; let’s just say some component, service, or platform can do it.
• Suppose the customer placing the order does not have an assigned agent.  The system should detect a fault, a violation of the business rule.  In other words, the system should become aware that the business rule is not satisfied by this new state of affairs.
• The system should respond immediately to the fault.  In lieu of any smarter response, at the very least it should respond with an appropriate message to someone, perhaps to the order-taker (assuming that worker is authorized and capable).

What exactly should the error message say? Obviously, the message can include all sorts of ‘help’.  But the most important thing it should say is what kind of fault has occurred from the business perspective.  So it could start off by literally saying, “A customer that has placed an order must have an assigned agent.”  We say the business rule statement is an error message (or better, a guidance message). That’s a system putting on a smart face, a knowledge-friendly face, at the very point of knowledge.  But it’s a two-way street.  By flashing business rules in real-time, you have an environment perfectly suited to rapidly identifying opportunities to evolve and improve business practices.  The know-how gets meaningful mindshare.  That’s a ticket to continuous improvement and true business agility.

Smarter and Smarter Responses

Is it enough for the system simply to return a guidance message and stop there?  Can’t it do more?  Of course. For the order-taking scenario, a friendly system would immediately offer the user a means to correct the fault (again assuming the user is authorized and capable).  Specifically, the system should offer the user another procedure, pulled up instantaneously, to assign an appropriate agent.  If successful, the user could then move on with processing the order. This smart approach knits procedures together just-in-time based on the flash points of business rules.  It dynamically supports highly-variable patterns of work, always giving pinpoint responses to business events (not system events).  In short, it’s exactly the right approach for process models any time that applying know-how is key — which these days, is just about always! The Business Rules Manifesto (http://www.businessrulesgroup.org/brmanifesto.htm) says this:  “Rules define the boundary between acceptable and unacceptable business activity.”  If you want dynamic processes, you must know exactly where that boundary lies, and how to respond to breaches (at flash points) in real time. Is that as smart as processes can get?  Not yet.  Over time, the business rules for assigning appropriate agents might become well enough understood to be captured and made available to the system.  Then when a fault occurs, the system can evaluate the business rules to assign an agent automatically.  At that point, all this decision-making gets tucked very neatly under the covers.  Even if the business rules you can capture are sufficient for only routine assignments, you’re still way ahead in the game. Smart architecture based on business rules is unsurpassed for incremental design, where improvement:

• Focuses on real business know-how, not just better GUIs or dialogs.
• Continues vigorously after deployment, not just during development.
• Occurs at a natural business pace, not constrained to software release cycles.

The Manifesto says it this way:  “An effective system can be based on a small number of rules.  Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter.”  That’s exactly what you need for knowledge retention, as well as to move pragmatically toward the knowledge economy.  Business rules give you true agility.

---

The OMG standard  SBVR[1] distinguishes between two fundamental kinds of business rules[2]:

• Definitional rules (including decision rules) are about shaping knowledge (and cannot be violated).
• Behavioral rules are about shaping conduct (and can be violated).

Question: Should definitional rules be included in business process models? Answer: You might have 100s or 1,000s of business rules about determining creditworthiness. In what sense is directly including all those business rules in a model of a business process useful? (Note carefully I said business rules, model, and again business (process).) So my answer is no, don’t include them. Question: Or, to put it another way, do we simplify business process models by removing only the behavioral rules? Answer: Again, no. Question: And am I right in assuming that these behavioral rules are associated with decision points in process flow charts, and what we are being urged to do is eliminate decision diamonds from those charts? Answer: Assuming you mean binary branch points in traditional flowcharts, I’ve seen both definitional and behavioral rules modeled procedurally by those. Traditional flowcharting is spectacularly unsuccessful for behavioral rules, because as I’ve said many times, each generally has two or more flash points[3] where it could be violated and needs to be checked. Those flash points could be in completely different flow charts (or procedures or use cases). Consider this simple business rule: An agent must be assigned to a customer that has placed an order. Flash points:

• When the first order is placed by a customer.
• When an agent leaves the company (which could leave an order-placing customer without an agent).

How likely is the second event to be handled by the same flowchart (or procedure or use case or even business process) as the first? That’s why business rules need to be a first-class citizen in the requirements world. It is also why we need ‘watchers’ outside the process (automated as much as possible) to:

• Detect violations of behavioral rules (like cops and referees).
• Permit dynamic invocation of selective (read “selectively different”) responses.

Call the result dynamic process or what you will; behavioral rules are the pragmatic means to stitch together highly responsive business activity in real-time operational activity. ~~~~~~~~~~~~~~~~ If you liked this blog post you might also enjoy: http://www.brsolutions.com/2012/05/01/r-i-p-straight-line-old-school-processes/

Celebrating the 10^th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #10 Question: How does the Manifesto view the issue of business rule enforcement? Principle 4.6 of the Manifesto states …

Rules should be defined independently of responsibility for the who, where, when, or how of their enforcement.

Why? Separation of rule specification from enforcement concerns[2] ensures that …

• The true business intent of the rule itself can be directly validated. Enforcement concerns do not mix things up.
• The greatest degree of business agility is achieved. Changes to enforcement specifications and changes to the rule itself can be made independently.
• The highest degree of re-use is supported. The same rule can be subject to different enforcement specifications at different points of application.

Specifying rules independently of responsibility for enforcement is taken to mean all the following.

• Who. If responsibility for enforcing the rule is given to some role in the organization, that role should not be mentioned in the statement of the business rule.
• Where. If responsibility for enforcing the rule is assigned to some component of the technical architecture, that component of the technical architecture should not be mentioned in the statement of the business rule.
• When. In general, every business rule applies to multiple events (flash points). However, those events should not be mentioned in the statement of the business rule.
• How. If capability for enforcing the rule is laid out in some process or procedure, that process or procedure should not be mentioned in the statement of the business rule.

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.

Consider the following behavioral business rule: A renter must not have possession of more than one rental car. In discussing enforcement of this rule, one reviewer said something to the effect, “We have to think about what happens ‘at the time of the decision’. Hold on. What ‘decision’?! I don’t see any decision. What ‘decision’ could he possibly be talking about? When it comes to behavioral rules and their enforcement, there’s no ‘decision’ in a meaningful business sense. Let’s think it through.

• There was the governance decision to create the business rule in the first place, but that’s not operational business activity per se.
• There might be a decision about whether and how strictly to enforce the rule, but that is an enforcement question, not an operational business decision either.
• If the decision is ‘Are we following our rules?’ that’s a bogus operational business decision. It might be valid as a test or simulation, but that’s not a decision per se either.

A good analogy for the enforcement of behavioral rules is a game of football. There are referees who ‘watch’ on-going (business) activity and throw a flag when a violation occurs. But they stand on the outside of the plays (processes) looking in. Now a player may ‘decide’ to violate a rule, but we frankly don’t care about individual ‘decisions’ of those kinds. We care only about the resulting (business) behavior (hence behavioral rules). Let’s return to the behavioral rule: A renter must not have possession of more than one rental car. Here’s the important point with respect to business processes. The rule is expressed declaratively. Although specified only once, it is presumably relevant to multiple business processes – e.g., for new bookings, rescheduling of existing bookings, extension of open rentals, late returns, etc. We call points in business processes where a rule needs to be tested ‘flash points’. Like the referees in a football game, a run-time business rule facility should be watching all on-going activity to detect violations anywhere and everywhere they might happen. You might say the facility is ‘deciding’ that violations occur, but who cares … again, those are not operational business decisions. For our purposes, violations either happen or they don’t. Don’t get me wrong. ‘Decisions’ do have an important place in both business rule thinking and in creating smarter business capabilities. But right now there seems to be a whirlpool of decision hype that’s sucking up altogether too many good brain cycles. We need to see what role decisions do play in business analysis clearly so we can exploit the new techniques to their fullest.

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