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.

For IT professionals the state of processes has always reigned supreme. In procedural approaches the internal state of a process is represented by some token. Most computer languages use that approach (the token generally falls through lines of code sequentially). Many current approaches to business process modeling do as well, at least implicitly. But why should business people care about the internal state of any process? For example, if a business person asks How far along are we in processing this order? the person is really asking: Has the order been credit-checked? Has it been filled? Has it been shipped? (etc.). In business operations it’s the state of each operational business thing that matters. True business agility cannot be achieved so long as business processes are perceived as managing state internally (privately). That’s a fundamentally flawed paradigm for business operation today. Instead, business processes must externalize semantics so business people can understand and manage the state of operational business things directly. Externalizing semantics is accomplished by means of SBVR-style structured business vocabularies (concept models) and single-sourced business rules. ~~~~~~~~~~~~~~~~~~~~~~~~~~ This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php  

Business Process Models: A completed transform often achieves a business milestone and a new state for some operational business thing(s). Example: claimant notified. Fact Models: In fact models (structured business vocabularies) such states are represented by fact types, for example, claimant is notified (or claimant has been notified if you prefer). A fact model literally represents what things the business can know (remember) about completed transforms and other operational business events. Business Rules: Business rules indicate which states are allowed or required. They should not reference business processes or business tasks by name, just the states they try to achieve. For example, a business rule might be: A claimant may be notified that a claim has been denied only if the specific reason(s) for denial have been determined.  ~~~~~~~~~~~~~~~~~~~~~~~~~~  This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php  

When the Business Rules Manifesto was published in 2003 (http://www.businessrulesgroup.org/brmanifesto.htm), I co-proposed the six items below related to business processes as an additional (eleventh) Article. The Business Rules Group (BRG) decided (probably wisely) to avoid that potentially controversial area, however, and concentrate on the core message of business rules. Since a Business Process Manifesto has been in the works, it’s worth going back over the proposed items. I believe they remain valid. So I dug them out of my Editor archives, cleaned them up a bit, and presented them below. Aside: In 2003 the BRG wasn’t careful about saying “business rule” (instead of just “rule”) and business process (instead of just “process”). But that’s what we meant – real-world rule and real-world process – not technical specifications. I’m very careful about that clarification these days. A great many people have a hard time seeing the difference. Item 1. Business rules guide business processes.

Comment: If this one is not self-evident, all bets are off.

Item 2. Business rules should be substituted for any activity in a business process where the result(s) of that activity can be produced by the business rules.

Comment: This item refers to what SBVR calls definitional rules – business rules that can derive, classify or compute something. For any given ‘something’, there might be only a single business rule, or a very large number of business rules. The ‘something’ could be an operational business decision requiring many dozens or hundreds of decision rules organized into decision tables.

One thing the item doesn’t say is that not all such ‘somethings’ need to be supported by business rules from the very beginning. In fact as Item 8.5 says, they don’t need to be. Business rules are very good for incremental development. (Development of what? Smart business processes.)

Item 3. Business rules can cause business processes to be initiated under appropriate circumstances.

Comment: Circumstances can arise that require the business to respond in a pre-scripted manner – e.g., low inventory status, potential fraud or intrusion, etc. Some business rule(s) should identify the circumstances involved in such ‘spontaneous’ business events.

Item 4. The default explanation or message for any error that occurs in a business process for a business reason is a business rule.

Comment: This item is truly ground-breaking. Business rules express the do’s and ‘don’ts’ of business activity; therefore, any error that occurs under a business process for a business reason is ‘explained’ by a business rule. What else could it be?!

Keeping systems carefully aside, and noting the obvious possibility of providing additional or alternative ‘explanations’, I like to say ‘the business rules are the error messages’. By the way, I’ve been saying that since 1994 – I have the slides (transparencies actually) to prove it. If you have doubts about this item, please provide examples(!).

Item 5. Any delay in the ability to enforce a business rule must be coordinated with business processes.

Comment: In SBVR, behavioral rules are business rules that can be violated. (Definitional rules can’t be.) An example where such delay might occur is a business rule that requires an approval or sign-off on something (e.g., an extra-large order on credit) by somebody (e.g., the branch manager) who is not immediately available. The business process for that particular something must be suspended until some future time.

Note: Additional business rule(s) providing appropriate suspense criteria (e.g., 24 hours) would be wise in such cases. We don’t want an order sitting in limbo forever(!).

Item 6. Business rules cannot constrain the workings of a business process directly, but only the following: (a) the state required for the business process to be performed; (b) the state while the business process is being performed; and (c) the results – that is, the state – the business process seeks to leave behind when finished.

Comment: I think of a business process as being like a black box with respect to business rules. The business rules cannot and should not ‘look’ inside. Instead, all matters of state should be externalized so business rules – and business people – can know it and talk about it. Get ready for this: This item indicts BPMN with its token-based approach to process state. The future lies with externalizing semantics. Sorry guys!