People are asking why current processes are so dumb. For example, why can’t they:
learn from experience?
be more goal-driven?
dynamically balance between conflicting goals?
Some people suggest use of cognitive computing to help make processes smarter. I doubt anybody today really knows how far this idea can be taken. I can, however, say two things with certainty:
If you don’t know what your business rules are (i.e., what rules guided previous executions), can you really expect a machine to figure them out? A machine can undoubtedly identify patterns, but that’s a far cry from demonstrating compliance, guaranteeing consistent results, or customizing appropriately case-by-case.
Suppose self-adapting processes do become reality. The question I have is what will keep such processes from going out of bounds? How do you avoid them doing things that are undesirable, self-defeating or even illegal? These are critical questions that will always bring you right back to business rules.
Jim Sinur recently wrote a short, readable and deeply thoughtful opinion piece on www.BRCommunity.com entitled “Is Process a Dirty Word?”. See http://www.brcommunity.com/b812.php.Jim’s basic point is this, “… people frown on the word process these days … [based on] the outdated view that process implies a rigid and inflexible approach to work actions that support a static business model.” I think Jim is right about that … and wrong too.Where Jim is Right. The main point Jim makes is right. Compared to traditional, static process models, processes are becoming highly dynamic. They can “not only can act, they can sense and decide new courses of action, leveraging a combination of pattern recognition and decision features based on events, cases, process instances, and data (big data or not; cloud based or not).”At the extreme, they essentially cease to exist as models “carved in stone”. Jim puts it this way: “In the future the process model will more represent the audit trail of what the process did and the decisions it made.” (Of course I think one can legitimately question whether a process model exists at all if it manifests only as facts about what each execution/performance of the process has actually done, but let’s let that go.)Where Jim is Wrong. Jim points out that “Processes are becoming more goal-seeking in their design and can change in near real time … processes will more commonly seek conflicting goals [and go about] balancing them.”When processes become ‘goal-seeking’ or ‘goal-balancing’, they address the question of ‘why’ (strategy), no longer just ‘how’ (transform). The resulting solution is a system, not just a process. Process is merely one component of such a system. By the way, I’m using system in the general dictionary sense, not in any particular technical sense: a complex unity formed of many often diverse parts subject to a common plan or serving a common purpose.Jim astutely points out that such processes can use “… pattern recognition [to analyze] the audit trails of past executions [and] identify what has worked best in the past under [the same] circumstances.” But surely audit trails (besides being data) are features of systems, not processes. And you’d always want to verify the results against business goals (which may conflict), and business policy (which may have changed).Should we call such processes intelligent? I wouldn’t. They’re just highly flexible. It’s the system that becomes intelligent. So these days I think we should be talking talk about FlexProcess and IntelligentSystem. By the way, can you do FlexProcesses and IntelligentSystems without business rules? Sure. Can you do them well? In your dreams.~~~~~~~~~~~~~~~~~~~~~~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 OMG standard SBVR distinguishes between two fundamental kinds of business rules:
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 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.
Consider the business rule: A vehicle must not exceed the posted speed limit. Some of the issues for this business rule are (a) how do you detect a violation and (b) how do you respond to a violation.These issues raise the question, whose process is it? Are we talking about the process of the person driving down the street, or the process of the policeperson operating the speed trap? The two processes are obviously related in some way, but definitely not the same. The cop’s process is best viewed as interrupting the driver’s process. Let me come back to that point in a minute.There are two fundamental kinds of business rules:
Decision rules (or a little more broadly, definitional rules). These are the kind of business rules that expert systems traditionally addressed. It’s the kind you find in decision tasks – e.g., whether someone should be given credit.
Behavioral rules. These are business rules that can be violated – e.g., speeding down the street, or being off-sides in football. For behavioral rules you need cops or referees or whatever to interrupt a more basic process when a violation occurs. It’s just the natural way to do things (if you don’t want anarchy).
Aside: You might say the examples of behavioral rules I’ve cited (speeding and off-sides) are not automatable. Well, I’m less and less sure about that these days. I see a lot of cameras where I live ‘watching’ for cars running red lights. The camera takes a picture of your license plate and the position of the car in the intersection and you get a ticket in the mail. For the record, I haven’t gotten one. But they do make me more careful about yellow lights.In any case, a great many behavioral rules are automatable. They arise as interpretations of some law, act, statute, regulation, contract, agreement, business deal, MOU, business policy, license, certification, warranty, etc. For these kinds of business rules, you need a ‘watcher’ outside the process, standing ready to interrupt the process if a violation occurs. A classic example: The fuel rods in a nuclear power plant must be covered with water. If a process of operating the power plant ever violate that rule, I want an immediate violation response to interrupt the guilty process(!).That business rule is about operating a power plant, but the same idea holds true for business processes in general. Detecting violations of behavioral rules is how you can stitch together dynamic processes in real time.Such dynamic processes cannot be achieved by embedding business rules in either a model of the business process, or the process itself. The ‘watcher’ must be on the outside, protecting the interests of the larger (business) community. Such rule independence is the fundamental idea of business rules, as expressed by the Business Rule Manifesto. R.I.P traditional, hard-wired processes!
In a recent post, Jonathan ‘Kupe’ Kupersmith said:
“In manufacturing following a process step by step is a good thing. In our world [business analysis] this is not the case. Following an A to Z process for every project is a bad thing. Every project is different. Different people, different risks, different priorities, etc. You need to adapt your process to meet the needs of the project.”.
I believe what Kupe is saying is that the ‘business analysis process’ is not a traditional straight-line process (like old-style manufacturing). Instead, it is what is currently being called (variously) a ‘social process’ or ‘dynamic process’ or ‘case-based process’. Such a process is:
Social in that interactions at various times with various people with various kinds of know-how must be orchestrated for optimal results.
Dynamic in that the ‘flow’ is highly situation-based rather than predictably straight-through (static).
Case-Based in that the ‘flow’ of events is based on the particular characteristics of the case (project) at hand, rather on forced conformance with some ideal.
Let me make a couple of observations (which are not points of disagreement with Kupe):
There are many, many companies (even in manufacturing) now beginning to understand that their core business processes should be organized as social/dynamic/case-based rather than traditional/static/straight-line. Customization and personalization of products and services demand it.
Achieving manageable customization and personalization at scale requires an appropriate infrastructure that is business-based.
The need for infrastructure leads inevitably to business vocabulary (business semantics) and business rules. (What’s the alternative??) So business rules are probably even more essential for social/dynamic/case-based processes than traditional/static/straight-line ones.
What do these observations specifically mean for the ‘business analysis process’? I would suggest the following:
Having a standard business vocabulary for the ‘business analysis process’ is key. How many organizations really have one? I see this omission as a huge hole in current BA standards and practices. (Plug: Our new book, Building Business Solutions: Business Analysis with Business Rules, has a 55pp Annotated Glossary. We practice what we preach. http://www.brsolutions.com/b_building_business_solutions.php)
The know-how to support a social/dynamic/case-based ‘business analysis process’ should be expressible as rules. If the know-how can’t be articulated and properly communicated, then how can the process be repeated, learned and scaled? Tacit know-how is simply no longer adequate in a knowledge economy.
“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
“A great class that explains the importance of business rules in today’s work place.”
Christopher – McKesson
“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.”