Know-How Models: How Business Rules, Decisions, and Events Relate in True-to-Life Business Models

Ronald G.  Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal and Co-Chair, Building Business Capability (BBC) Read Author Bio       || Read All Articles by Ronald G. Ross
Excerpted with permission 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, October 2011, 304 pp.  URL:

Business analysis with business rules focuses on capturing, encoding, and managing a specific kind of knowledge — operational business know-how.  (We call it know-how for short.)  Know-how is represented in the form of business rules based on a structured business vocabulary (fact model).  In many respects the fact model, with its business terms and definitions, is the most fundamental know-how of all.

Decision analysis, a special area of business analysis with business rules, focuses on developing decision rules.[1]  Your organization undoubtedly has a great many decision rules, but it also has a great many behavioral rules.

Behavioral rules govern the conduct of on-going business activity by 'watching' for violations.  Example of a 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, nor does it apply only at a single point of determination (e.g., when a case of a student wanting to join a team comes up).  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.  In other words, the business rule is about shaping (governing) the conduct of on-going business activity.

Understanding how behavioral rules work is essential in creating true-to-life business models, which we call know-how models.  Table 1 identifies fundamental differences between behavioral rules and decision rules.

Table 1.  Behavioral Rules vs. Decision Rules

Behavioral Rules

Decision Rules





Shaping (governing) the conduct of on-going business activity

Providing answers for repetitive questions arising in day-to-day business activity

Featured Kind of Business Rule

Business rules that can be violated

Business rules that indicate the correct or best outcome for some case

Most Common Original Source

Interpretation of some law, act, statute, regulation, contract, agreement, business deal, business policy, license, certification, service level agreement, etc.

Judgments or evaluations made by subject matter experts

Special Analysis Techniques

Pattern Questions[2]


Role in the Business Model

Prevent situations (states) the business deems undesirable

Ensure consistency of operational business decisions

Point(s) of Evaluation

Each operational business event where the business rule could be violated

The single point of determination in day-to-day business activity at which an operational business decision is made for a case

Most Frequent Representation

Generally fit no pattern, so usually must be expressed as individual statements (e.g., using RuleSpeak[4])

Generally fall into patterns, so often can be expressed in decision tables

Drill-Down to Additional Business Rules

Yes, significant drill-down to underlying definitional rules

Yes, significant drill-down to underlying definitional rules

Quantity in a Typical Business Capability

A great many

Each decision table has multiple — overall, a great many

Flash Points

As mentioned above, behavioral rules generally need to be applied at various points in time.  What are these points in time?  How can you find them?  Why are they important for Business Analysts?

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 produces two or more kinds of operational business events where it could potentially be violated or needs to be evaluated.  (We mean produces here in the sense of can be analyzed to discover.)

These operational business events are 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 quick notes in passing:

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

Your Current IT Requirements Approach: 
The Big Question

Each business rule usually produces multiple flash points.  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:  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?!

How to Assemble a Know-How Model:  Case Study

Let's walk through a case study to understand how behavioral rules, flash points, and operational business decisions should relate in a business model.

Scenario:  A customer places an order.

Flash point:  The operational business event "when a customer places an order" is a flash point for some behavioral rule(s).

Behavioral rule:  A customer must be assigned to an agent if the customer has placed an order.

Motivation:  The business thinking behind the business rule is briefly:

The company's products are complex, expensive, and available in a large variety of configurations.  Customization is often warranted.  Assigning an agent helps customers identify the best solution for their particular circumstances.  Assisted acquisition also ensures the highest chance of customer success and reduces returns and replacements.

This business thinking is the motivation for the business rule — its pedigree.  The motivation should be recorded (as part of rulebook management) and accessible to everyone properly authorized.  Never assume the original motivation for a business rule will be remembered and properly understood by all.  Document it!

Violation event:  The particular customer placing the order does not have an assigned agent.

Detection of the violation:  Some staff person, business rules engine (BRE), or other platform recognizes that an agent needs to be assigned.  That staff person, BRE, or other platform did not 'decide' the customer needed an agent.  No operational business decision or choice among alternatives is needed to recognize the violation.  An order being placed by a customer without an agent simply results in a violation of the business rule.

Response to the violation:  Something must be done to assign an agent to the customer.  When the business rule was created, the company decided the best violation response would be to hand the case over to a line manager and let her handle the situation.  Presumably, she's in the best position to know which agent is optimal to assign to any given customer.

Operational business decision:  The need to pick and assign a particular agent from among alternatives for the given customer at the given point in time does represent an operational business decision.  The business is trying to answer the question Which is the best agent to assign to a customer?  The manager decides and assigns an agent for the given case.  Business activity moves on from there.

Potential decision analysis:  The operational business decision has been identified and included in a list of possible targets for future decision analysis.

As illustrated by this case study, the dynamics of behavioral rules are fundamentally different from those of decision rules.  The differences are summarized in Table 2.

Table 2.  Differences in the Dynamics of Behavioral Rules vs. Decision Rules

Behavioral Rules

Decision Rules

Key Concern

Shaping (governing) on-going business behavior

What business question is being asked

Central Issue for Analysis

Detection of violations and the appropriate response to such violations

What is the correct or optimal answer for each case at a given point in time

Is Choice Involved?

A violation of a behavioral rule just happens.  No choice is involved in the detection of a violation.

Choice is center stage.  A choice among alternatives (outcomes) is always involved.

Enforcement of behavioral rules involves three things:  enforcement level, guidance message, and violation response.[5]  Each behavioral rule should be examined along those three lines in creating true-to-life business models.

Decision Analysis and Know-How Models

Returning to the agent-assignment rule, let's say the company recently decided to automate the operational business decision:  Which is the best agent to assign to a customer?  The Business Analysts will have:

  • Undertaken decision analysis and created a Q-Chart.

  • Developed decision tables, spending time with business leads to get the decision logic right.

Then the decision logic is deployed under a business rule engine (BRE).  Now, instead of the line manager performing the decision task 'manually' as each case arises, the BRE does it automatically by evaluating the decision tables.  No matter, it's still an operational business decision — a selection or choice among alternatives to be made in real time.  Note that the decision logic can be evaluated as a violation response for the original behavioral rule:  A customer must be assigned to an agent if the customer has placed an order.

From a business perspective, automation of the operational business decision changed only two things, both for the better:

  1. The line manager has been freed up to do other (perhaps more challenging) work.

  2. Her know-how has been encoded so the company won't lose it should she leave.  Decision logic, like all business rules, is inherently about know-how retention.

When Operational Business Decisions Should Be Made

In the know-how model described above, the decision logic for the operational business decision, Which is the best agent to assign to a customer?, can be invoked as a violation response for the behavioral rule.  Do decision rules have flash points too?  Yes, but the implicit assumption in decision analysis is that evaluation of decision rules need not be based on their own flash points.

In general, the default point of determination for decision rules is case-based.  In other words, an operational business decision is made for a case simply because either the particular case is ready for the decision or the related circumstances demand it.

Example:  An order has been filled and packaged and is ready to be shipped to the customer.  All behavioral rules have been satisfied.  Now the correct or optimal delivery method for shipping the package needs to be selected (an operational business decision).  The correct or optimal answer is determined by evaluating the decision rules.  Afterwards, things move along as per the business process (e.g., the package is shipped).

Reversible Decisions

Sometimes, as in this example, once a decision is made for a case there is no practical way of turning back.  In other words, barring some unforeseen scenario, the operational business decision is final (irreversible).

Not all operational business decisions have that degree of finality.  In essence some decisions can be reversed or improved, at least for a period of time.  Indeed, not revisiting such decisions can prove counter-productive, wasteful, or even dangerous.

Example:  An agent needs to be assigned to a customer.  Unfortunately, all the agents most highly qualified for that customer are currently unavailable or overloaded with work.  The best approach might be to assign an interim agent, then revisit the case later.  You never know, a highly qualified agent might suddenly shake loose in the next little while.

As this example suggests, a reversible decision can be revisited by introducing time-based criteria (some business rule(s)) to re-evaluate selected cases after a certain period of time, perhaps repeatedly.  The possibility of significant over-time improvement in reversible decisions is always worth exploring.

Could you achieve the same result in a business process model?  Adding business task(s) downstream in a business process model for the purpose of improving earlier decisions is usually not recommended (too complex).  A better approach, especially for last-chance improvement opportunities, is to include some appropriate business milestone(s) in a business milestone model.[6]

Available Resources in Short Supply?

Some operational business decisions are characterized by a potential shortfall in resources relative to demand.  For example, a car rental agency at an airport might not have enough rental cars of the right models to satisfy all outstanding reservations.

The best approach in such circumstances is generally to wait as long as you can to make any decision.  During the delay, you save up a 'batch' of incoming cases, then make decisions for the whole batch at once.  This approach ensures the best possible match-ups for higher-priority cases.[7]

Example:  Reservations from high-status customers might come in at the beginning of the delay period, but rental cars of the requested models might become available only toward the very end.  Had you assigned rental cars in real-time (i.e., as each reservation is received), your aggregate solution would be suboptimal for the time period.  In plain English, suboptimal means your best customers are needlessly unhappy.

The trick, of course, is determining how long a delay in making the decisions is too long.  Answering that question involves analyzing trade-offs among your business goals.  Remember, we're not modeling know-how for the sake of the know-how.  We're modeling it for the sake of deploying the best-possible business solution!


Operational business know-how is complex, involving both behavioral rules and decision rules.  Understanding their intertwined roles is key to creating high-quality, true-to-life business models and, from them, effective business operation systems.  Treating business rules as a first-class citizen also shifts your focus toward operational business events, especially flash points.

Business Analysts should not work down to business rules in use cases or other system models; business rules should be a primary focus in creating a business model.  The resulting know-how model will be unbeatable in its support for business agility and knowledge retention.


[1]  BRS In-Depth White Paper:  Decision Analysis Using Decision Tables and Business Rules.  Available free on www.BRSolutions.comreturn to article

[2]  Refer to Chapters 5, 7, 9, 11, and 15 in Building Business Solutions:  Business Analysis with Business Rules, to article

[3]  Ronald G. Ross, "Introducing Question Charts (Q-Charts™) for Analyzing Operational Business Decisions:  A New Technique for Getting at Business Rules," Business Rules Journal, Vol. 11, No. 12 (Dec. 2010), URL: to article

[4]  See (free). return to article

[5]  Refer to Chapter 15 in Building Business Solutions:  Business Analysis with Business Rules, to article

[6]  See Chapters 10 and 11 in Building Business Solutions:  Business Analysis with Business Rules, to article

[7]  Sometimes call pattern matching by business rule management systems (BRMS). return to article

# # #

Standard citation for this article:

citations icon
Ronald G. Ross, "Know-How Models: How Business Rules, Decisions, and Events Relate in True-to-Life Business Models" Business Rules Journal, Vol. 12, No. 11, (Nov. 2011)

About our Contributor:

Ronald  G. Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal and Co-Chair, Building Business Capability (BBC)

Ronald G. Ross is Principal and Co-Founder of Business Rule Solutions, LLC, where he actively develops and applies the BRS Methodology including RuleSpeak®, DecisionSpeak and TableSpeak.

Ron is recognized internationally as the "father of business rules." He is the author of ten professional books including the groundbreaking first book on business rules The Business Rule Book in 1994. His newest are:

Ron serves as Executive Editor of and its flagship publication, Business Rules Journal. He is a sought-after speaker at conferences world-wide. More than 50,000 people have heard him speak; many more have attended his seminars and read his books.

Ron has served as Chair of the annual International Business Rules & Decisions Forum conference since 1997, now part of the Building Business Capability (BBC) conference where he serves as Co-Chair. He was a charter member of the Business Rules Group (BRG) in the 1980s, and an editor of its Business Motivation Model (BMM) standard and the Business Rules Manifesto. He is active in OMG standards development, with core involvement in SBVR.

Ron holds a BA from Rice University and an MS in information science from Illinois Institute of Technology. Find Ron's blog on For more information about Ron visit Tweets: @Ronald_G_Ross

Read All Articles by Ronald G. Ross

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.