Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

To: Business Process Manifesto … From: Business Rules Manifesto … Re: How Business Processes and Business Rules Relate

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!

Tags: , , , , , , , , , , , ,

Ronald G. Ross

Ronald G. Ross

Ron Ross, Principal and Co-Founder of Business Rules Solutions, LLC, is internationally acknowledged as the “father of business rules.” Recognizing early on the importance of independently managed business rules for business operations and architecture, he has pioneered innovative techniques and standards since the mid-1980s. He wrote the industry’s first book on business rules in 1994.

Comments (24)

  • Jon Struthers

    |

    I like some of the things that you have stated, although I am not sure I necessarily agree or disagree with it all (will require a bit more thought). I think that Item 2 might be a little strong given the situation (or just “can be produced” isn’t as well defined as it should be) there are instances where a result could be produced by a business rule, but given the context you wouldn’t want it to be so. For instance auditing, you could conceivably audit a set of financial accounts through a well written set of business rules … and in a lot of the cases this may even produce a more accurate result, however, there are also legal implications to such activities … the net result of it is that the result can be produced by a business rule, but it also can’t be produced by a business rule. A hard and fast “you should always preference the business rule” probably isn’t what you are going for anyway here, but it leaves room for poor process results if blindly followed.

    With regards to Item 6, I am a little unsure as to whether I would agree that to be complete or not. Here is my thinking, if asked to identify the different scenarios where a rule could be used in a process I would suggest the following 3. To control the flow (decision points), to control the ownership (swimlane/task assignment) or to manipulate the process data (as an implementation of an activity/task).

    My understanding of what you have for Item 6 is that it controls the flow of the process, and the data in the process (both of which are expressed by the abstract notion of state). However, I am not convinced that “state” as a concept adequately captures the idea of task ownership as well, I would liken the state of the process more to what is going on and what has happened than who is actually assigned to do the work, that to me seems to sit just outside the bounds of process state, although it is clearly strongly coupled. I can see an argument that state could include “currently assigned to …” but I would suggest the concept of ownership is significant enough that it would warrant being explicitly stated.

    • Ronald G. Ross

      Ronald G. Ross

      |

      @Jon

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

      >>The purpose of Item 2 is simply to avoid hardcoding business rules into procedural code. The point is that *any* business rule could potentially change. Separate from any (behavioral) business rule is its enforcement level and the appropriate response(s) to its violations. These two things need to be worked out as a business proposition to ensure appropriate, consistent results. I think this covers your point??

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

      >>Just a quick clarification: If we are truly talking *business* process, then we should not be talking ‘data’. Data is how you represent what you know about the real-world in a system (data store). A business process should be seen as working with real-world things … even if intangible. (An insurance policy or bank account is very real to the people that hold them.)

      With respect to assignment of tasks (work), I think you mean dynamic assignment of tasks (as in load balancing or something?). But in any case, “state” always means “what we can know about things that happen”. If knowing about assignments once made is important to the business, then it should be considered part of (business) state.

      The rule of thumb is: If an operational business thing is important enough for the business ever to talk about it, then it needs to be considered part of (business) state.

      Does that cover it?

  • Jon Struthers

    |

    Item 2 makes more sense now, although I am still not sure if it needs to be as strongly worded as it is. But I guess that also comes back to “what is a business rule” and all of those other wonderful discussions, and I would definitely be willing to concede that conceptually there is a business rule behind most tasks on a process diagram (possibly even most nodes of the diagram). So I guess the important detail from an implementation standpoint would be to identify that you are talking more broadly than a business rules as managed through a “Business Rules Management System”.

    Item 6, you certainly got me on the data point. In fact I had a bit of a paragraph to explain why I included that even though it wasn’t really accurate from a theoretical perspective. My basic thoughts though, in a purist process model it’s all about communication, thus we could probably get away with removing that third category all together … because the “data” concept disappears in favor of (or merges into) communicating processes, so changing flow will allow us to effect the state of the underlying things business assets in the required fashion effectively merging the “data” and “flow” categories I had above. However, that said most of the BPMS implementations I have seen still very much hold the concept of data very sacred … and as such from a practical point of view it can be useful to call it out specifically.

    That said, I can see where you are going with Item 6, and am happy to take the point.

    For clarification, I was meaning dynamic assignment (whether that be on the task or a swimlane) load balancing would be one possible application, the scenario that jumps to mind more readily is approval hierarchies where approval always happens, but at design time we aren’t sure of the specifics of what manager needs to click the button. e.g. in a procurement request, ordering a truck may differ in approval to ordering a pencil, and there would be two types of business rules I see here, the first determines how many levels, which is not about assignment but rather about flow, and the second determines who the appropriate manager is for the current level given the context, this would be the dynamic assignment I was aiming for.

    • Ronald G. Ross

      Ronald G. Ross

      |

      @Jon –

      You said: “I guess the important detail from an implementation standpoint would be to identify that you are talking more broadly than a business rules as managed through a “Business Rules Management System”.”

      >>When I say “business rule” I *always* mean real-world rules needed to run the business … no matter how and where implemented or deployed.

      You said: “e.g. in a procurement request, ordering a truck may differ in approval to ordering a pencil, and there would be two types of business rules I see here, the first determines how many levels, which is not about assignment but rather about flow, and the second determines who the appropriate manager is for the current level given the context, this would be the dynamic assignment I was aiming for.

      >>You have a decision analysis problem there, with at least several considerations, and probably multiple subdecisions. Decision analysis can and should be undertaken independently of process analysis. For more about decision analysis, see:

      http://www.brcommunity.com/b600.php
      http://www.brcommunity.com/b605.php
      vhttp://www.brcommunity.com/b609.php

  • Paul Konnersman

    |

    Ron, you say “…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.”

    I’m afraid that I’m one of them. What rules and processes are you excluding with the “real-world” modifier?

    • Paul Konnersman

      |

      Ron, Thanks for the clarification. However, I don’t think I would be able to identify a “production rule” amongst a group of “ordinary” rules. Nor do I see the relevance of what “business people” do or don’t do. I also think I could make a case that some business people do indeed set variables and call functions, although they might not recognize those descriptions of what they do.

      I see rules (all rules) as programmatic ways to make decisions and decisions (all decisions) as choices between two or more alternatives.

      • Ronald G. Ross

        Ronald G. Ross

        |

        @Paul – By “real-world” rule, I’m excluding (e.g.,) production rules as in expert systems. Don Baisley, a colleague of mine on the SBVR team, said: “Business people don’t set variables and they don’t call functions.”

      • Ronald G. Ross

        Ronald G. Ross

        |

        @ Paul – Production rules are pretty easy to spot … they follow a condition-action (or event-condition-action) syntax. See http://en.wikipedia.org/wiki/Production_system.

        When I was doing bakground research on business rules in the 1990s, I bought rulebooks for baseball, basketball, football (American) and soccer. Makes interesting reading (if you’re into that sort of thing). I guarantee ‘condition-action’ syntax is not how the rules in those are expressed. Or look at any contract. Or any frequent-flyer program. I could go on (and on). My point is that to ensure effective business communiation, we should be speaking business rules as people talk about real-world rules.

        Business rules are about business behavior, not implementation. That’s why I’m careful to say *business* rule. And a subset of business rules, yes, are about making operational business decisions.

  • Roger Burlton

    |

    I respect Ron’s views on the Business Process Manifesto which was inspired by the Business Rules Manifesto. So far there have been lots of feedback in the Business Process Manifesto blog about rules. Since it is a business process work I would prefer we keep the rules-specific principles out of the business process manifesto and let them stand on their own two feet. However I would like to include the ones or variants on them that Ron has brought forward which help us understand the Busness Rules and Business Process interrelationships since they each have a dependency that needs to be better understood and articulated. The Business Process Manifesto does have some coverage of the topic but it seems that it needs to be more explicitly stated. Thanks for the contribution.
    Roger

  • Neal McWhorter

    |

    This topic of business rules and business process integration has been something I’ve spent a great deal of thought into over the last 10 years. While I believe that I understand the reasoning behind the various principles I have a different take. I believe the whole business world might well be able to be described as business rules. But the fact that they might be able to be described as such doesn’t necessarily mean that they should be described that way. Years ago Ron you commented to me something along the lines that “processes don’t really exist they are just what we perceive from patterns defined by business rules”. That comment has flitted around in my mind ever since. Here’s where I’ve come around to. Processes, Rules, Events, Terms and Facts are all useful metaphors because they simplify certain problems. However, when one metaphor is used excessively it looses its power. So I might describe the whole business world using business rules but by doing so I’ve probably given up a substantial amount in comprehensibility. And comprehensibility translates into lower cost and more rapid change. So here’s how I fit things together:

    1) For paths and activities that are relatively stable I use processes. These are much easier to understand than using business rules to describe the same.
    2) For situations that trigger business processes I use events (with rules to describe when the event occurs in those circumstances where we need to get to that level of detail).
    3) For activities which are very formulaic I use a variety of representations from mathematical to decision trees to optimization techniques.
    4) For activities which have a great deal of flexibility but are constrained I use rules to capture the constraints and state models to capture the possible situations.

    Based on this I offer the following comments on the principles

    Item 1. Business rules guide business processes.
    Some business rules are expressed as paths within processes. Other are expressed as constraints about which paths can be followed in which circumstances. But typically we don’t think of these as business rules because it is easier to treat these as elements of a process and thereby not ease the comprehension problem that an all-rules based approach would create.

    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.
    Definitional rules should be isolated from a process via a concept. So the definition of a “Good Customer” is provided by a set of rules but a process should only be concerned about whether a customer is a “Good Customer”. The fact that the concept is derived by rules should be hidden from the process.

    Item 3. Business rules can cause business processes to be initiated under appropriate circumstances.
    Situations that cause a business process to be initiated should be treated as events and the definition of that event is the set of rules that capture the situation that trigger the event.

    Item 4. The default explanation or message for any error that occurs in a business process for a business reason is a business rule.
    I’m not sure I believe that the absolute version of this is practical but certainly this is the benchmark that we should strive to achieve. One of the difficulties is that unless you describe everything in the business world with rules then not all errors can be the results of rules. This gets back to the whole comprehensibility issue since I maintain that treating everything as rules has a negative impact on comprehensibility.

    Item 5. Any delay in the ability to enforce a business rule must be coordinated with business processes.
    Since a business process is where business work is done it is certainly true that a violation needs to be coordinated with a business process. In fact I’d say that a rule must make the violation known so that a process can respond. Here again though treating the violation as an event and the rules as merely the definition of the event allows the process model to have a consistent way of responding to any circumstance rather than leaving it open as I think this principle does.

    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.
    This is probably the most overlooked principle. I call this “using knowledge to decouple processes from rules”. There should never be a process that has an activity that says “check this rule” or “check this set of rules”. Processes check knowledge (the equivalent of ‘state’ in this principle) and if that knowledge happens to be rule-driven then so be it. That is, with one exception. Some process control rules check the state of the process directly (e.g. check if the process has at least 2 active incoming flows) which don’t justify the confusion it would create to give a name to the knowledge.

    My comments don’t negate any of the principles but I would like to believe that they add a seasoned perspective from someone who has spent years practicing on both sides of the fence.
    Neal

    • Ronald G. Ross

      Ronald G. Ross

      |

      @ Neal, said: “Years ago Ron you commented to me something along the lines that “processes don’t really exist they are just what we perceive from patterns defined by business rules”. That comment has flitted around in my mind ever since.”

      >>Neal, Do you have anything in writing or in a slide where I said that?! It doesn’t sound like me at all, so I believe I either expressed myself badly, or you heard something I didn’t say exactly as you remember.

      Here’s why. I’ve been a believer in the Zachman Framework for at least two decades, probably more. In the beginiing, Zachman talked only about the first three columns, but even then, process (‘how’) was one of the big 3. I have never doubted the existence of process (input-transform-output).

      What I’ve always doubted was the wisdom of rigid processes. The analogy I’ve always used is baking a cake. I’m not a chef, so I better follow the recipe. The great chefs of Paris … they can probably still get good results not following the recipe.

      What I may have said is something like “what most people think of as processes are actually the [rigid] results of patterns expressed by business rules”. I still believe that. Given geographical, product-specific, and time-variant differences in practices, rigid processes simply will not work. You want recipes (yes, processes), with core financial and business practices locked in by business rules, but otherwise allowing for pervasive local variation.

      • Neal McWhorter

        |

        Ron,

        You may be right about me having the comment wrong. It happened at one of… possibly the first… joint meetings between the OMG and the Business Rules Group. Sometimes what sticks is the impact the comment made rather than what was actually said. I accept that I’ve probably misquoted you. It wasn’t my intent to make the focus on whether or not you actually said this so I should probably have left it out. But whatever was actually said certainly did start me thinking those many years ago now and I haven’t stopped since. I consider that a good thing so I appreciate your original comment… whatever it was… which is probably now lost to history.

        Neal

        • Ronald G. Ross

          Ronald G. Ross

          |

          @Neal, You said: “But whatever was actually said certainly did start me thinking those many years ago now and I haven’t stopped since. I consider that a good thing “.

          >>I violently agree!

    • Ronald G. Ross

      Ronald G. Ross

      |

      Neal, On Item 1 Business rules guide business processes … You said:
      “Some business rules are expressed as paths within processes. Other are expressed as constraints about which paths can be followed in which circumstances. But typically we don’t think of these as business rules because it is easier to treat these as elements of a process and thereby not ease the comprehension problem that an all-rules based approach would create.”

      >>As Roger Burlton famously says, “You have to separate the know from the flow”. Processes are input-tranform-output. That’s what the primitive is. I’m all for modeling them. But for business people I want 4 pages, not 40. The way to do that is to take out the guidance — all guidance, any guidance and express it separately. Business people have no trouble with that — just the opposite, it’s a huge relief.

      • Neal McWhorter

        |

        Actually I think we’re saying the same thing coming from different directions. My point was exactly that we have to shrink the size of the problem’s complexity in order to allow the audience to more readily understand it. Separating guidance out is one piece of doing that in the right circumstance.

    • Ronald G. Ross

      Ronald G. Ross

      |

      Neal, On Item 4. The default explanation or message for any error that occurs in a business process for a business reason is a business rule. … You said “I’m not sure I believe that the absolute version of this is practical but certainly this is the benchmark that we should strive to achieve. One of the difficulties is that unless you describe everything in the business world with rules then not all errors can be the results of rules. This gets back to the whole comprehensibility issue since I maintain that treating everything as rules has a negative impact on comprehensibility.”

      >> I never said treat everything as rules. Never. I beleive in the six Zachman primitives (columns), none of which are rules. I believe, like you, in events, which are composites. And of course, I certainly believe in business rules (as composites).

      Anyway, give me an example of a *business* rule that you can’t put into words.

      • Neal McWhorter

        |

        Ron, I wasn’t intending to claim that you said that everything should be treated as business rules. I just used this as a strawman because the existing principles you outlined didn’t illustrate the multi-faceted ways that the various analytic elements interact.

        I also think you missed my point here because I don’t say that I think there are business rules that you can’t put into words. What I’m trying to illustrate is that in a world where choices of metaphors exist a business rules is not always the metaphor being chosen. Because of this not all errors will make sense to describe in terms of business rules. A process that cannot end and has no business rules controlling the flow is a business error yet it makes little sense to describe such an error in terms of business rules exactly because it has not been specified in terms of business rules.

        • Ronald G. Ross

          Ronald G. Ross

          |

          @Neal – You said: “A process that cannot end and has no business rules controlling the flow is a business error “.

          >>Why can’t the process end? IAC, I think both of your examples point to bad practices in process modeling. Business rules, however, are always about operational business activities. Process *design* is not that. Call them design rules if you like.

          • Neal McWhorter

            |

            Ron, my experience is that these kinds of errors happen all the time *operationally*. It is true that these do reflect design errors and that they often indicate a missed rule but my point was that we must deal with the kinds of inconsistencies that organizations have to work through on a daily basis.

    • Ronald G. Ross

      Ronald G. Ross

      |

      Neal, On 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. … “There should never be a process that has an activity that says “check this rule” or “check this set of rules”. Processes check knowledge (the equivalent of ‘state’ in this principle) and if that knowledge happens to be rule-driven then so be it. That is, with one exception. Some process control rules check the state of the process directly (e.g. check if the process has at least 2 active incoming flows) which don’t justify the confusion it would create to give a name to the knowledge.”

      >>Business people don’t care about the state of a process. They care about the state of things. So your exception is not a *business* rule.

  • Neal McWhorter

    |

    Ron, Here I differ with you. Business people do care about the state of a process. The state of a process is just as much a thing as anything else. Process improvement is often heavily focused on creating rules about the state of a process. I’m not sure how you could see this differently.

    • Ronald G. Ross

      Ronald G. Ross

      |

      @Neal – You said “Business people do care about the state of a process. The state of a process is just as much a thing as anything else.”.

      >>A business person might ask, “Has the order been credit-checked”? “Has the order been filled?” “Has the order been shipped?” These are questions about facts — facts regarding the state of a business thing, order.

      How would a business person articulate questions about the state of a process? Business processes manipulate *things*. The states of those things are what business people care about.

      • Neal McWhorter

        |

        Ron, I think our difference here comes down to whether or not one assumes that all facts can… or should… be reified onto non-process business concepts. I think that doing this introduces rigidity into business processes which is why I would avoid what you suggest in the example you cite. I’d would claim that some facts are best dealt with as facts about processes.

  • The Implementation Business Rules Manifesto » Dulcian, Inc.

    |

    […] professionals come to a mutual understanding of the scope and nature of the system.  I submit that Ron Ross refers to these types of “analysis rules” in his Manifesto (see Business Rules Concepts 4th ed. […]

Comments are closed