To understand the future of processes, you must dig a little deeper than many people do. Process thinking goes back well over a 100 years, to the origin of modern iron and automobile production. The raw materials and finished goods of such manufacturing and production processes are literally spatial – 3-dimensional. What can you do to significantly improve productivity in a 3-dimensional world? The answer these days is simple: You build robots. Robotization has literally changed the world during the past 30-40 years. Rather than manufacturing and production processes, however, the world is now increasingly focused on white-collar and digital processes. What 3-dimensional presence do the raw materials and finished goods of these processes have? Well, exactly none. The raw materials and finished goods of these processes aren’t physical and simply have no spatial presence whatsoever (except maybe for paper artifacts). Robots (at least physical ones) aren’t an option. That fact of life makes a huge difference in how you have to think about automation for such processes. Instead, the raw materials and finished goods of such processes are all about your operational business knowledge – your intellectual capital – and your capacity to express and apply it. That capability, in turn, depends directly on your business terminology and business language. For white-collar processes you have no choice – the world is semantic. So you must deal with the subject matter semantically. That takes us in a very different direction than most professionals currently foresee. For one thing it takes us toward natural language and away from diagrams-for-everything. That’s a huge shift in mindset. Imagine having a business conversation with your smart phone about gaps and ambiguities in business policies and in the meanings of the vocabulary you use to talk about subject matter knowledge. Don’t think that’s possible? Have you watched your kids talking to their smart phones lately? Sooner or later businesses will realize that operational business knowledge differentiates their product/services and enables their ever-more-automated processes to function. Capturing, managing and re-using that intellectual capital puts a premium on structured business vocabulary (concept models[1]) and on business rules expressed in structured natural language[2]. Those business rules are the only way you have to ensure quality from white-collar and digital processes. ~~~~~~~ Read more on this topic: Are Processes and BPM Relevant in the Digital Economy? http://www.brsolutions.com/2015/10/19/are-processes-and-bpm-relevant-in-the-digital-economy/ Measuring Quality and Defects in the Knowledge Economy: http://www.brsolutions.com/2015/10/27/measuring-quality-and-defects-in-the-knowledge-economy/ Quality and Tolerances in the Knowledge Economy: http://www.brsolutions.com/2015/10/29/quality-and-tolerances-in-the-knowledge-economy/ ~~~~~~~~~~~~~~~ www.BRSolutions.com

---

Quality must be viewed very differently in the white-collar world. The traditional view simply doesn’t fit. In Henry Ford’s day, for example, central to the concept of mass production was standardization of parts. That idea leads directly to the notion of manufacturing tolerances – i.e., upper and lower limits for parts in 3-dimensional space. The goal is to ensure physical interchangeability of physical parts. That idea is now standard practice, of course, across manufacturing and production sectors. But what are the ‘parts’ in white-collar work? White-collar processes simply don’t deal with physical things. How can you identify tolerances for them in 3-dimensional space? You can’t! In a very real sense, the ‘parts’ in white-collar work are literally just bits and bytes. If not tolerances as a basis for quality, then what’s the proper focus? My answer: consistency and reliability of results. For example, if I visit ten different branches of the same bank about getting a mortgage for my dream home, shouldn’t I get the same answer on my application from all 10 branches?! As you perhaps have experienced yourself, that’s not the way it works in many banks today. So one aspect of quality in white-collar work is the consistency and reliability of operational business decisions. Another aspect of quality concerns compliance. Every business is subject to ever growing numbers of (take a deep breath here) … acts, laws, statutes, regulations, contracts, MOUs, agreements, terms & conditions, deals, bids, deeds of sale, warranties, prospectuses, citations, certifications, receipts, legal notices … and the list goes on. Shouldn’t I expect consistency and reliability of results with respect to all those obligations and commitments? I believe we should. If it’s not about quality, then what?! My conclusion:When there isn’t any physical product from a business process, quality and defects must be measured by consistency and reliability of results, which are in turn always purely a matter of business rules. For background on this post, see: http://www.brsolutions.com/2015/10/27/measuring-quality-and-defects-in-the-knowledge-economy/ ~~~~~~~~~~~~~~~ www.BRSolutions.com

I’ve written on this subject many times before, but let me summarize my position concisely. By the way, I expect heavy flak on the last point. See what you think. (1) Business rules should be expressed declaratively based on common business vocabulary.

An implication for business rules: No direct invocation of functions.

(2) No reference whatsoever should be made to events in expressing business rules.

Exception: Some business rules (a small minority) truly apply only at the time a given business event occurs. Example: A hotel guest must be given fresh cookies upon check-in.

(3) Behavioral rules (unlike decision rules) should always be evaluated immediately when any relevant event occurs. Such ability supports real-time compliance. (Read about behavioral rules vs. decision rules on http://www.brcommunity.com/b623.php.)

One Implication: You have to know what those relevant events are.

(4) The events to which a declarative rule applies can (and should) be determined automatically.

USoft proved the principle 20 years ago. SBVR’s treatment of business rules is based on the assumption.

(5) It’s important to determine the events automatically for behavioral rules because that way you can take programmers out of the business of event detection and management.

The benefits of doing so would be immense.

(6) Events bear a direct relationship to business rules in the sense that behavioral rules need to be invoked automatically when events occur.

How else can you achieve comprehensive consistency of behavior?!

(7) Business rules bear no such direct relationship to processes.

Do we really want programmers and designers to remain in the business of event detection and management forever?! In my opinion that’s a very bad idea.

(8) Some (many?) business capabilities (e.g., highly social ‘processes’) could be modeled and run without business process models altogether.

How would it work? You need:

• Declarative business rules.
• Work milestones (states through which loosely organized work still must progress).
• Automatic event identification (as in USoft).
• Event detection and management (as in Tibco).

 

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.

Business Process Models and Business Rules … Separate the ‘Know’ from the ‘Flow’ Conditional flows are one of the most important features of a business process model. For example, a business process model for handling claims would include multiple conditional flows – e.g., if valid claim, if claim approved, if fraud suspected, etc. A conditional flow simply means that work follows the given path only if the condition is satisfied for a given case. The secret of effective business process modeling with business rules is never embed the criteria used to evaluate a conditional in the conditional itself. Instead, just name the conditional using an adjective (e.g., valid) or past participle (e.g., approved). The criteria for evaluating conditionals should always be expressed separately as business rules. Fortunately there’s nothing particularly hard about that. Example: A claim may be considered valid only if it has an incident date. Following this best practice is how you keep a business process model simple – often by an order of magnitude or more! Frankly, most business processes aren’t nearly as complicated as people think. What’s complicated is the know-how needed to perform the business process correctly. That know-how should be represented by business rules. P.S. I first heard the phrase ‘separate the know from the flow’ from Roger Burlton on 11/30/1999. I immediately made a note because it was so memorable and on-target.  ~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

Let me mention two important things happening soon and special discounts for them – Both discounts good only through **Friday, September 30**   1. ANNOUNCING OUR NEW BOOK … Coming in October! BUILDING BUSINESS SOLUTIONS: BUSINESS ANALYSIS WITH BUSINESS RULES … an IIBA Sponsored Handbook (304pp) … It’s all about taking Business Analysis to the next level of capability.  http://www.brsolutions.com/bbs >> Receive 25% off the book’s list price of $39.95 if you pre-order now. Use discount code **BBS1001**.  2. BUILDING BUSINESS CAPABILITIES CONFERENCE (BBC 2011) … Oct. 31 – Nov. 3, Ft. Lauderdale, FL  http://www.buildingbusinesscapability.com/  The must-attend conference of the year covering all things ‘business’.  Four conferences in one for a total of 9 tracks … on pace this year to be a sell-out!  >> Receive a 15% discount on registration. Use discount code **RRBBCFL**.  * Business Analysis Forum, the Official Conference of the IIBA. http://www.buildingbusinesscapability.com/baf/ * 14^th annual Business Rules Forum Conference. http://www.businessrulesforum.com/ * The 1^st annual Business Architecture Summit. http://www.buildingbusinesscapability.com/bas/ * The Business Process Forum. http://www.businessprocessforum.org/

Here’s a short clip about business rules from an interview in Amsterdam not too long ago. I actually agree with what I said … http://www.youtube.com/watch?v=fhv7bGf3r3Y&feature=related There are several related clips there with John Zachman, Roger Burlton, and Silvie Spreeuwenberg (LibRT) worth a few minutes of your time — business rules, decisions, business processes, enterprise architecture, and more.

On an EA LinkedIn group last week, Nick Malik wrote the following about business rules in Zachman Framework 3.0: “I’ll bite. If the ‘enterprise ontology’ is similar to the periodic table of elements, then business rules are molecules. They are compositions of elements with specific implications, embedded in event handling logic. Why would you expect to see them, or models of them, on the Zachman Framework? OK… that was my humble, and perhaps uninformed, opinion. You are the master of business rules. You tell me where you’d see them.” Nick, You know the definition of ‘master’, right? Same as ‘expert’ … someone who has made all the known mistakes. Zachman and I have had over-dinner conversations for many years about the question of where business rules fit (or don’t) in the Framework, even more so in the past couple of years. I won’t speak for John, but I think he agrees. Yes, business rules are ‘molecules’ and yes, they are ‘composites’. So you don’t see business rules anywhere in Framework 3.0. Instead, if you look at the new cross-column thin gray lines, at row 2 in particular, some or many of those could be business rules. Aside: For convenience, here’s a zipped pdf of the new 3.0 version (with permission): ZF3.0.zip [approx 1.5M]. Visit Zachman’s new website for all the latest. The thing about molecules or composites – unlike the primitives – is that they can be conceived in many different ways. Each conceptualization leads you to a different representation approach, and each representation approach leads you ultimately to a particular implementation strategy. Some implementation strategies, of course, are better than others (by a mile!). Moving Beyond the Big-P Approach At the risk of over-simplification, you have two basic choices for conceptualization, and ultimately implementation, of composites: procedural or declarative. Historically, we have embedded business rules in process models and in procedural code. We have taken the column 2 (how) primitive, process, and used it to create composites. At the scale of today’s business, this Big-P process paradigm simply doesn’t work. Why? The thin gray lines in Zachman 3.0 are really about how the business is configured for operation. (At row 6 the thin gray lines represent the current actual configuration of the operational business.) In the Big-P paradigm, all building-block ‘molecules’ become thoroughly entangled with flow (input-transform-output). The result is essentially a semantic dead zone. You’re never sure what things really mean, and you can’t easily disentangle them. There are no built-in impediments to replication … and no opportunity to use logic to automatically evaluate configurations (models/designs) for conflicts, anomalies and other logical defects. Aside: The Big-P approach also has implications for data models. In current practices, there is no way to automatically perform any meaningful verification of data models either. The future lies with granular, declarative, semantically-rich specification of building-block composites (‘molecules’) for configuration. I know I used the ‘S’ word there (‘semantics’) but I’m simply talking about structured business vocabularies (SBVR-style fact models). Fact models, by the way, must cover anything with a name, including instances from columns 2-6, so they too are composite rather than primitive. Aside: Was I happy to see John use the ‘O’ word (‘ontology’) in 3.0? I think I know why he did it – to emphasize the Framework is not a simple taxonomy, but rather something rigorous enough to potentially reason over. I’ll let others judge that choice. Re-factoring the Big-P Paradigm Clearly, business rules are one building-block composite for disentangled forms of enterprise configuration. Another thing not considered a primitive – Nick mentioned them – are events. They too possess the granular, configurable potential of business rules. And yes Nick is right – events and business rules have a very close relationship, one not widely appreciated. (If the industry did, it would already be taking a very different approach to process modeling.) Aside: But no, Nick, I would not ’embed’ business rules in ‘event handling logic’ … no more than I would embed ‘event handling’ in business rules. Unfortunately, expert systems do allow you to do that. What else do we need as building-block composites to configure an enterprise at a given point in time? Let me propose decisions – but with caution. ‘Decision” is the buzzword de jeure. No, decisions are not a cure-all, no they do not replace business rules or events, and no they do not solve all our problems. But in proper perspective, yes, they are most definitely a building-block composite. Smart Configuration Models Big-P configuration of the enterprise is like setting it in concrete. To replace that flagging paradigm we need smart configuration models. Such models will feature at least: (a) business rules, (b) business events, and (c) operational business decisions. And of course, structured business vocabularies (fact models). Smart configuration models should be the new mantra for enterprise architecture. In a world of constant and accelerating change, I see no alternative. By pinning down the primitives definitively in 3.0, Zachman has opened the door to a whole new realm of rich architectural potential. But there’s more. Smart configuration schemes must address additional challenges facing business today. These include business governance and compliance – essential in a world of constant change – and just-in-time (JIT) delivery of know-how for operational workers. In our new book coming out the end of September, we call systems built using smart configuration schemes business operation systems (BOS), as opposed to ‘information systems’. I think you’ll find these new ideas quite exciting. Watch for them!

@SergeThorn asks “Are Business Process Management and Business Architecture a perfect match?” http://goo.gl/kLYvs With business rules far better! There is an important overlap of concerns between business rules and enterprise architecture. The overlap actually comes in two forms: 1. Operation-time. Here the issue is really rethinking compliance. I just blogged about this today: http://goo.gl/Gl9wT 2. Business-analysis-time. A business needs to know the rules it plays by. That inevitably brings you to rulebook management. For more: http://www.brcommunity.com/b500.php?zoom_highlight=rulebook (and other articles).

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!