Charles Darwin is reported to have said, “It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.” Becoming more responsive to change is simply not optional these days. Consider the current state of affairs in IT today. The statistics are depressing. Reliable sources indicate that over 75% of all IT resources go toward system ‘maintenance’. That’s not agile! In the second of edition of Building Business Solutions: Business Analysis with Business Rules, Gladys Lam and I describe this world as like living in change deployment hell.You might say that legacy systems are poorly engineered, but I believe that misses the mark. Rather, perhaps they are be over-engineered. What happens when you over-engineer something? The solution you produce is too stiff or too rigid or too cumbersome for the real-world problem. Think ‘tree that doesn’t bend with the wind’. The speed of business is accelerating, yet the architecture of traditionally-built systems is rigid and static.The fundamental problem in this regard is embedding business rules within the systems themselves. If you hard-code business rules into application logic, they will be hard to find, hard to understand, and even harder to change. Do we really want to keep building systems that way?!Make no mistake about it – many business rules will change. So if you continue hard-coding business rules into systems, you will be revisiting the code … a lot! That might be a good thing for service providers, but it’s not a good thing for the business.The obvious solution is to engineer business rules separately from functional requirements. Can you do that cleanly and effectively? Absolutely. It’s been proven many, many times. ~~~~~~~~~~~~~~~~~~~~~~~~~www.BRSolutions.com
Your ability to respond in appropriate ways to pinpoint circumstances where business rules are breached – automatically and independently of processes – provides the mechanism you need to support very smart, very friendly business systems. Normally we think about breaches occurring for behavioral rules, where a breach means a violation has occurred. Can breaches occur for decision rules too? The answer is yes and no. Read on!
A breach occurs for a business rule when the business rule isn’t satisfied upon being applied to some set of circumstances (state of affairs). Normally we think about breaches occurring for behavioral rules, where a breach means a violation has occurred (e.g., you violated the posted speed limit).
The potential for violations of behavioral rules raises several important questions that business analysts should answer in advance of deployment for each behavioral rule:
1. What level of enforcement should be applied.
2. What special response to a violation is appropriate, if any.
3. What special message, if any, should be returned to some worker(s) upon a violation.
Unlike behavioral rules, no definitional rule can ever be violated. Literally, things must be correct under such rules by definition.
Let’s take an example. Suppose somebody asserts “2+2=5”. According to the rules of mathematics, we know the correct answer is 4. The answer “5” is deemed irrevocably wrong. But is the asserted answer ever allowed to stand?
If the rule is defined as a decision rule, the asserted answer is never allowed to stand. More precisely, the assertion would never be recognized to have happened in the first place. If someone asserts “2+2” the answer “4” is concluded immediately. Period. No breach, no opportunity for error.
If defined as a behavioral rule (one that is not strictly enforced), the asserted answer is allowed to stand, but a violation is recognized. How might that capability be useful? Suppose the error were made by a student in grade school. It might be quite useful for the student and/or a tutor to know about it immediately and automatically. Specifying an appropriate violation response can make such notification happen.
In business, of course, definitional rules can be far more complex. Nonetheless, your ability to respond in appropriate ways to the pinpoint circumstances where certain rule-related events occur – automatically and independently of processes – provides exactly the mechanism you need to support very smart, very friendly operational business decision systems.
Decision Rules and Breaches
Decision rules are a special kind of definitional rule involving implications (e.g., A implies B). They support inferences and determinations – identifying an appropriate outcome from among a set of alternatives.
Like all decision rules, definitional rules cannot be violated. They are simply deemed true by definition.
Purely from a business perspective, however, some assertions of fact(s) may make it appear that a breach-like event has occurred. I take pains to emphasize any such perception is purely from the business perspective, not from the perspective of logic. You perceive a breach of a decision rule simply because it’s useful to do so, not because any true violation has occurred.
In evaluating some particular case (situation, set of circumstances, or matter of concern), for example, things might not follow the ‘happy path’. Think of a breach of a decision rule as a bump in the road – a gap along the happy path.
Let’s return to the three questions listed earlier. Although the first question about enforcement level obviously doesn’t apply to decision rules, adjusted versions of questions 2 and 3 remain in play.
Consider the following simple business example. Suppose a bank has this decision rule:
A credit application must be considered discrepancy-free with respect to a credit report for the applicant if all the following are the same:
date of birth
Social Security Number
Let’s suppose that an applicant uses just the initial for her middle name on her credit application. If the credit report shows her full middle name, then the names are not the same and the credit application will not be considered discrepancy-free.
Note carefully the rule hasn’t been violated; it did its ‘work’ correctly and it did reach the proper conclusion (not discrepancy-free). But a gap – a breach – for her case has been identified from a business perspective because the rule failed on one of the conditions. We should be able to take advantage of that breach to take appropriate action – selectively, automatically and in real time.
For example, the desired response to the breach might be to insert the following to-do item in the work queue of the responsible staff member: “Review discrepancy and manually ok if appropriate”. (The to-do item should naturally also provide ready access to the related documents.) The breach of the rule causes this action to occur automatically.
Think about how many decision rules might exist for determining credit-worthiness, and how many selective conditions they might have. Could you build a responsive system by incorporating the selective responses needed into the related process model(s)? Not a chance – that approach won’t scale. Instead, the selective responses need to be specified based on the business-rule side of things.
Kinds of Breach Specifications for Decision Rules
Breach specifications for a decision rule can be of the following two kinds.Breach Response. A breach response can be an action of virtually any kind. For example, a breach action might be to:
Add some task(s) to a (non-redundant) to-do list in some appropriate work queue.
Add some documentation items to a (non-redundant) not-yet-received list.
By these means very selective follow-up processing/handling (“what to do next”) can be organized pertaining to any specific issue (breach) for a given case. Such selectivity is made possible by the granularity of the rules.
Breach Message. A specially-worded breach message can be forwarded to any involved party either inside or outside the company. A breach message generally explains one or both of the following at any level of detail desired:
Why the rule or condition failed. (The rule or condition statement already indicates very precisely what the issue is, but the breach message can explain in a more friendly manner.)
What should be done to address the issue.
More Complex Example
Breach specifications apply selectively and specifically to a decision rule and/or any of its conditions. A breach specification applies if and only if that decision rule and/or condition fails (is not true) in evaluating some specific case (e.g., a specific credit application). An example of a decision rule with condition-specific breach specifications is illustrated in Table 1.
Table 1. Example of More Complex Decision Rule with Condition-Specific Breach Specifications
A fluctuating income must be considered eligible if all the following are true:
Conditions of the
the applicant has a 3-year proven track record of consistent income
the applicant is likely to have comparable income in the future
Add to-do item for that credit application: “Contact employer to verify applicant has reasonable opportunity for future income.”
the income is validated
Add required documentation items not yet received to a pending list for the credit application.
To applicant: “[date] Here’s a list of documentation items related to your income we have not yet received. [pending list].”
Using Breach Specifications
Breach specifications can be:
General for an entire decision rule including all its conditions. (The example in Table 1 doesn’t include any whole-rule specifications. If the rule did they would appear in the first row.)
Specific to a given condition.
Specific to collections of conditions (none shown for the example).
A breach is detected only if the conclusion of the rule as a whole, or some particular condition within it, evaluates to not true. Things being true should be viewed as moving the case along the desired path (i.e., no breach has occurred). Decision rules (and breach specifications) should be expressed carefully so as to preserve this positive orientation.
Generally, breach actions should be specified only if something can be done to overcome a failure (of a rule or condition). The goal is to move things forward in the case. In the example above, for instance, if nothing whatsoever can be done to correct an issue, the credit application should simply be declined. A behavioral rule to that effect should be specified.
In hierarchies of decisions (e.g., as in Q-Charts) and decision rules (e.g., as based on series of logical dependencies), breach specifications should generally be made only at the lowest level of rule reduction/decomposition. A rule at a higher level in a logical hierarchy only evaluates to not true if some rule(s) below it evaluate to not true. Define breach specifications at the lowest level of granularity.
Although rules can be specified in violation specifications for behavioral rules (e.g., to express some sanction or penalty), they should never be specified within breach specifications for a decision rule. Such ‘nesting’ of rules, especially on the basis of ‘not true’, is inappropriate.
Otherwise the advantages of overall declarative specification can be forfeited.
By default, breach specifications for a decision rule apply only the first time it is evaluated for each case. The assumption is that all business rules, including decision rules, are evaluated on a continuous basis. Re-application of any breach specification for a case therefore requires additional timing and iteration criteria. Whether a case is evaluated iteratively on the same set of decision rules based on timing criteria applied by or for some external process or platform is outside the scope of this discussion. No matter what the scheme of evaluation, the expression of the decision rules – as for all business rules – should be completely unaware of it.
The point of knowledge (POK) is a real place. POK is where know-how – business rules – are developed, applied, assessed, re-used, and ultimately retired. In other words, POK is where business rules happen.
When you start to fully understand business rules, a whole lot of other pieces of the puzzle fall right into place. You arrive at smart architectures, which gives you smart knowledge management and smart processes.
In smart architecture, business systems become knowledge companions, enabling never-ending, on-the-job training. Flash points of knowledge – real-time evaluation of business rules – enables dynamic processes and personalized, just-in-time delivery of up-to-date guidance.
A smart architecture is one equipped to address the formidable challenges facing businesses today – the accelerating rate of change, massive customization, and products and services that are ever richer in knowledge. Effective engineering of the POK is the new litmus test for agility.
The question you should be asking: How do you get your company tothe point of knowledge?
Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4th ed, 2013), by Ronald G. Ross, 162 pp,http://www.brsolutions.com/b_concepts.phpwww.BRSolutions.com
Location: Online Seminar
Do your business processes always produce correct and consistent results? If not the problem probably lies with your business rules and decision logic. Business Analysts need the right techniques to fix these problems – process models, use cases, data models and other requirement techniques just aren’t right for the job. This hands-on series will equip you with proven techniques for success.
More info: http://www.attainingedge.com/online-training-business-rule-analysis-masterclass.phpRegister for full series!
Session 1. The why, what and who of business rules
Next Session: October 1, 2013 @ 10:30am – 12:00noon (ET)
Why business rules
What benefits you can achieve
What business rules are, and are not
Business rules vs. business processes
Kinds of business rules: definitional vs. behavioral
How the business should react to violations
Business rules and decisions
What skills you need to capture business rules effectively
Location: London, England
Do your processes always produce correct and consistent results? If not the problem probably lies with your business rules and decision logic. Business Analysts need the right techniques to fix these problems – process models, use cases, data models and other requirement techniques just don’t do the job.
Business Rules are criteria used to judge the correctness of business behavior and to make operational business decisions. Many Business Analysts have not been exposed to the well-formed, in-depth body of best practices and standards developed over the past decade for this area. These techniques have proven invaluable in developing better business requirements. This seminar explains how business rules can be expressed, analyzed, validated, and managed as easily and as quickly as possible.
Decisions are choices made in day-to-day business operations. Such decisions are highly repetitive – they might be taking place hundreds or thousands of times per day, per hour, or even per minute. They are predictable and well-structured in terms of the outcomes they produce. New, highly pragmatic techniques have emerged in just the past several years for top-down decision analysis. The results are ultimately organized into decision tables, a set of technique all Business Analysts should know.
This hands-on workshop gives you essential tools that can help you achieve order-of-magnitude improvements in business capabilities. The result is simpler, smarter process models and a huge boost in business agility. Learn applied techniques from the recognized world leader in the field.
* Conduct smarter, more effective business analysis
* Identify and analyze decisions in business processes
* Use the most effective techniques to harvest business rules
* Write clear, business-friendly rule statements
* Create robust decision tables
* Validate business rules and decision logic with business people
* Identify anomalies and correct them early
* Perform concept analysis
* Develop a structured business vocabulary (fact model)
* Develop pragmatic visualizations
* Establish comprehensive traceability for your business rules
* Develop a pragmatic rule management approach
More information: http://www.irmuk.co.uk/events/75.cfm
Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4th ed, 2013), by Ronald G. Ross, 162 pp,http://www.brsolutions.com/b_concepts.phpLet me use an example to sketch the workings of business rules in smart architecture based on points of knowledge. 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.
You can find definitions and discussion of all terms inblueon Business Rules Community:http://www.brcommunity.com/BBSGlossary.pdfFrom 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, http://www.brsolutions.com/bbs~~~~~~~~~~~~~Discussion … First a definition to make sure we’re on the same page …
incremental design:developing a system through repeated cycles (iteratively) and in smaller portions at a time (incrementally)
Business rules are unsurpassed for step-by-step enhancement of deployed know-how in business capabilities over time (incremental design). The Business Rules Manifesto puts 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 know-how retention and to move pragmatically toward the know-how economy. Support for incremental design with business rules is quite straightforward. For example, a decision task might start off manual (performed by humans). As time and resources permit, decision rules for handling the simplest cases can be captured and encoded, removing these cases from the manual workload. Perhaps you start supporting a modest 20% of all cases. The only required changes to the system to support additional cases are to specify:
(1) What new cases are covered (by providing appropriate selection criteria).
(2) What new outcome(s) are needed (if any) for the new cases covered.
(3) What new (encoded) decision rules should be used for the new cases.
At a subsequent time, you ramp up to 50% of all cases, then perhaps 80%. You may never get to 100% – nobody is talking about taking humans completely out of the loop for every operational business decision(!). The net result is simply applying human resources where best suited, the really hard cases.
I am pleased to announce that a comprehensive set of authoritative FAQs about the Business Rules Manifesto has been added to BRcommunity.com: http://www.brcommunity.com/brm.phpThe Manifesto is celebrating its 10th anniversary this year – and remains as powerful and as vibrant to today’s business challenges as ever. I will be covering a good many of its insights in my Sunday tutorial, Business Rules: The Why and the What, at this year’s Business Rules Forum conference, part of BBC2012 (Oct. 28 – Nov. 2, Ft. Lauderdale, FL): http://www.buildingbusinesscapability.com/The FAQs explain in-depth how the Manifesto relates to a great many pressing issues on today’s business agenda, including …
The new BRCommunity Insider also provides insight into the general positioning and structure of the Manifesto, as well as point-by-point clarification of individual Principles.The Manifesto is just 2-pages and free. It has now been translated into some 15 languages: http://www.businessrulesgroup.org/brmanifesto.htm
The Manifesto is a rare thing in our field – a timeless work that seems more and more prescient which each passing year.
Let me re-clarify what I am, and am not, saying about business rules and black swans. There’s been some confusion. I did not say that preparing for or responding to black swans is all about business rules. (I’m not that naive!)I did say, however, that business rules “… build robustness to negative [black swans] that occur and being able to exploit positive ones” [Taleb’s words].
My main point is this: If you don’t have ready access to your current business rules (i.e., know what they are in depth), then when a black swan occurs you can’t immediately undertake to respond to negative ones, and exploit positive ones. (See: http://goo.gl/Ny2Cn)
A colleague wrote: “For example, Taleb cites 9/11 as an example of a black swan. What business rules would prevent or allow successful response to that?”
I make no suggestions about prevention. Hindsight is 20-20.
But successful response? You need to quickly review what your current business practices (business rules) are …
Permissible carry-ons. Box-cutter knives? Immediately banned. Any other sharp items including silverware for meals, banned.
Access to the cockpit. Special barriers (food cart, steward(ess)) put in a blocking position when a pilot exits the cockpit to use the lavatory. Doors locks reinforced.
We learn as we go. Amounts of liquid over a certain threshold, banned. Shoes must be removed at security. Souvenir ‘blizzard’ globes, banned.
You want to roll out these new business rules fast(!). If you don’t know what business rules you already have in place, you simply can’t respond as fast you need to. Make no mistake, most businesses today sadly don’t really know what their current business rules are. That’s what I’m saying!
I’ve gotten a lot of excellent response to yesterday’s post on black swans. Let me summarize yesterday’s points and continue the line of thought.
a. Business rules cannot be used to help protect against unforeseeable events that have not already happened.
b. Business analysts can assess unforeseeable events (black swans) and develop business rules to cater for their potential recurrence.
c. If you don’t have ready access to your current business rules (i.e., know what they are in depth), then when a black swan occurs you can’t immediately undertake point b.
Point c is actually where my emphasis lies. The result is that the organization remains vulnerable for recurrence (and copycat malicious attacks) for a much longer period than necessary (or desirable).How long extra? At least days, more likely weeks, sometimes months.What most organizations don’t realize today is that they don’t actually know what their business rules are. Before they can even begin to rethink business practices in-depth they have to send out ‘scouts’ (business analysts and IT professionals) to discover their current business rules (from people’s heads, source code, procedure manuals, documentation, etc., etc.). When the scouts do find the current business practices (business rules), they have to sort through redundancy, inconsistency, gaps and conflicts. That’s simply no way to run a business! There’s no single-sourcing of business rules, no official, authoritative ‘rulebook’, no structured corporate memory. The result is huge loss of time and energy.The problem is so big it’s hard to see. We simply have to face up to the fact that current methodologies produce a crippled business governance process. And yes, the situation *is* that bad!~~~~~~~~~~~~~~~~~
P.S. To single-source business rules and retain corporate memory about them, we recommend a ‘general rulebook system’. See http://www.brcommunity.com/BBSGlossary.pdf (page 30) for quick explanation.
“You did a wonderful job!! The material was organized and valuable.”
Janell – Texas State University
“I found the course interesting and will be helpful.
I like the pragmatic reality you discuss, while a rule tool would be great, recognizing many people will use Word/Excel to capture them helps. We can’t jump from crazy to perfect in one leap!
Use of the polls is also great. Helps see how everyone else is doing (we are not alone), and helps us think about our current state.”
Trevor – Investors Group
“Sessions flow together well and build upon the concepts for the series which makes the learning easy and better retention.
The instructor is knowledgeable and very attentive to the audience given the range of attendees skill and knowledge of the subject at hand. I enjoy her training sessions.”
Deborah – American Family Insurance
“Instructors were very knowledgeable and could clearly explain concepts and convey importance of strategy and architecture.
It was a more comprehensive, holistic approach to the subject than other training. Emphasis on understanding the business prior to technology considerations was reassuring to business stakeholders.”
Bernard – Government of Canada
“We actively use the BRS business-side techniques and train our business analysts in the approach. The techniques bring clarity between our BAs & customers, plus more robust requirements for our development teams. We’ve seen tremendous value.”
Jeanine Bradley – Railinc
“A great class that explains the importance of business rules in today’s work place.”
Christopher – McKesson
“Your work has been one of the foundations of my success in our shared passion for data integration. It has had a huge impact on innumerable people!”