Business processes and business rules #2
This follows Business processes and business rules #1 in a series exploring the relationship between business processes and business rules.
It is adapted from a paper on Business Process Architecture and the Workflow Reference Model [Lawrence (2007)1] which appeared in the 2007 BPM and Workflow Handbook published by the Workflow Management Coalition (WfMC). The full paper is available from www.makeworkmakesense.com.
The party line
To quote business rules guru Ronald Ross at greater length:
Processes are processes, and rules are rules. They are not the same. A fundamental principle of the business rule approach is that each is a primitive. Formally, one primitive can never decompose to another primitive. So processes never decompose into rules, and rules never decompose into processes…
[Ronald G. Ross (2003)2]
…business rules are not “process” in any sense of the word. Roger Burlton recently expressed the business rule message this way: “Separate the know from the flow.” Business rules represent the “know” part of that – the stuff that guides the “flow.” Guidance means following rules, of course – hence the name “business rules.”
[Ronald G. Ross (2000)3]
What idea of ‘business process’ does this presuppose? Ross’s ‘best definition’ is:
Business process: the tasks required for an enterprise to satisfy a planned response to a business event from beginning to end with a focus on the roles of actors, rather than the actors’ day-to-day job.
[Ronald G. Ross (2005)4]
Rules and business processes interact (Ross quoting Roger Burlton again):
…business processes “…transform inputs into outputs according to guidance – policies, standards, rules, etc….”
[Ronald G. Ross (2005)5]
The process is the ‘flow’ – a script – and the rules are the ‘know’ which guide the flow. So for example in making a cake, the script might be:
1. Combine flour, water, milk, and eggs in a large bowl.
2. Mix until batter is consistent but not entirely free of lumps.
This recipe represents a perfectly acceptable (albeit very simple) procedure or script. … Now let’s ask, what rules do we need?
Potential rules to provide appropriate control might include the following:
Milk must be fresh.
Bowl must be large enough so that contents do not spill out when stirred.
Batter may be considered “entirely free of lumps” only if there are no visible masses of congealed batter larger than 2 cm in diameter.
These rules represent business knowledge that must be present when the procedure or script is performed. …I want both a script to follow … and rules to guide me in doing the work. But most importantly, I want the script and the rules to be separate.
[Ronald G. Ross (2003)6]
There is also the concept of ‘surrogates’:
How does any model of the business (including its processes) differ from any model for the design of an information/knowledge system (including its processes)?
John Zachman7 describes the crucial difference this way. A business model “… is about real-world things.” A system model, in contrast “… involves surrogates for the real-world things so that the real-world things can be managed on a scale and at a distance that is not possible in the real world. These surrogates are the things making up … systems….” [emphasis added]. The most obvious kind of surrogate for real world things is data. A system process includes actions that manipulate data in various ways…
…A process in an information/knowledge system … can manipulate other kinds of surrogates as well, for example:
The supervisor’s work queue is actually a surrogate for a face-to-face interaction between a supervisor and an order clerk each time a special order is received.
The supervisor’s GUI for displaying orders in the queue is actually a surrogate for the flesh-and-blood order clerk.
A system process then is all about manipulating surrogates standing in for real-world things. A business process, in contrast, should never include tasks or steps for manipulating surrogates. That’s a big difference…
[Ronald G. Ross (2006)8]
A voice of dissent
I have no problem with the idea of surrogate as representation – in the sense that (say) a customer data record is a surrogate for a flesh-and-blood customer. But it does not follow that a ‘supervisor’s work queue’ is ‘a surrogate for a face-to-face interaction between a supervisor and an order clerk each time a special order is received’ or that a ‘supervisor’s GUI for displaying orders in the queue’ is ‘a surrogate for the flesh-and-blood order clerk’. The analogy does not hold. The flesh-and-blood customer exists, and the customer record represents the real-world entity. If Fred the flesh-and-blood customer did not exist there would be no customer data record representing Fred. The customer data record does not replace, or provide an alternative implementation of, the real customer. This is to see system functionality as primarily representing concrete entities and the relationships between those entities, both of which pertain to a specific (and perhaps historically prior) process implementation. And this, in turn, is to fall into the trap of automating the ‘as-is’ which has bedevilled IT since its early days.
I will try to explain what I mean, in the context of Ross’s example.
Some of the rules for the supplier’s order process will be criteria for deciding if an order is ‘special’. At a particular point in its history the supplier may have implemented its order process by having a flesh-and-blood order clerk and a flesh-and-blood supervisor. The order clerk would have applied those criteria and referred ‘special orders’ to the supervisor via ‘face-to-face interaction’. But consider an alternative where the order clerk only captures the order, and stored system rules decide if an order is ‘special’ and, if so, route it to the supervisor. There is no ‘face-to-face interaction’ for the supervisor’s work queue to be a surrogate for. Or consider another implementation where customers capture their own orders, and therefore there is no flesh-and-blood order clerk, but there is a flesh-and-blood supervisor complete with work queue. Or where there is no flesh-and-blood order clerk and no flesh-and-blood supervisor, and instead of routing to the supervisor’s work queue, special orders invoke special processing requesting references direct from banks and/or special credit checks direct from credit agencies.
Sequencing the scenarios like this may suggest an evolution of ‘improvement’. History may have been like this, but it may not have been. There may never have been an order clerk or a supervisor. These are just different implementations with different features, costs and technical feasibilities in different contexts. Even if things had happened in the order the scenarios were presented, a later scenario is not a surrogate for an earlier one. Something cannot be a surrogate for something which may never have existed.
The false analogy of ‘process surrogates’ is of a piece with the ‘best definition’ of business process quoted previously in terms of
tasks required for an enterprise to satisfy a planned response to a business event from beginning to end with a focus on the roles of actors.
[Ronald G. Ross (2005)9]
Why should there be actors? There may be actors, and if so they are likely to have roles. But to assume actors and roles are necessary to the business process is as unwarranted as to assume system functionality is necessarily a ‘surrogate’ for a more concrete (or flesh-and-blood!) implementation which must have preceded it.
It is possible that assumptions like these are behind the curious statement that a business process ‘should never include tasks or steps for manipulating surrogates’.
What do seem to be necessary components of business processes on the other hand are rules. To that extent I agree with Ross and Burlton that business processes ‘transform inputs into outputs according to guidance – policies, standards, rules, etc.’ But I see no residue of ‘script’ which is not rules. ‘Flow’ is also ‘know’. It is completely arbitrary to see ‘Milk must be fresh’ as a ‘rule’ but ‘Combine flour, water, milk, and eggs in a large bowl’ as part of a ‘script’, and therefore not a rule – just because ‘I want both a script to follow … and rules to guide me in doing the work’ and ‘I want the script and the rules to be separate’.
More about rules in the next section…
1 Chris Lawrence, Business process architecture and the Workflow Reference Model. In Layna Fischer (Ed.), BPM & Workflow handbook 2007, Future Strategies Inc, Lighthouse Point, Florida, 2007; in association with the Workflow Management Coalition.
4 Ronald G. Ross, How Rules and Processes Relate ~ Part 2. Business Processes, Business Rules Journal, Vol. 6, No. 11 (Nov. 2005), URL: http://www.brcommunity.com/b256.php. The quotation is from Janey Conkey Frazier.
7 John A. Zachman, The Zachman Framework: A Primer for Enterprise Engineering and Manufacturing (electronic book). Zachman International (2002).
© Chris Lawrence 2008