thinking makes it so

There is grandeur in this view of life…

Business processes and business rules #3

leave a comment »

Third in a series exploring the relationship between business processes and business rules.

Previous sections:

Business processes and business rules #1

Business processes and business rules #2

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

So what is a rule?

At an empirical level, there may well be contexts where

The really rapid change is in the rules … not in the business processes

[Roger T Burlton (2005)2]

For example there will be scenarios where the steps themselves and their sequence do not change much, but things like authorisation limits and role assignments do.

But equally, and particularly in pursuit of automation efficiency, a process implementation could change significantly (eg withdrawing cash from an ATM rather than cashing a cheque) while the fundamental rules stay the same (account and amount must be specified; withdrawal must be by a person authorised to withdraw from that account; withdrawal amount subject to limits; etc).

Far from separating ‘process’ from ‘rules’ a more helpful paradigm would be to see process completely in terms of rules. In terms of strict logical typing it may be that ‘process’ and ‘rule’ are different things, as ‘computation’ is not ‘number’ and vice versa. But it does not follow from this that the steps and their sequence which make up the entire content of the process are not rules. In fact I have yet to find a convincing argument to prove that a business process itself isn’t a rule at a logical level. Structurally there can be rules within rules. And if an organisation sees an event as a ‘request’ which it then intentionally honours, it is effectively following a rule it has been given or has given itself.

So the fundamental principles of Ross’s business rule approach seem to be pure dogma:

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)3]

A more helpful distinction would be between the process itself at logical (rule) level and any particular implementation of it – in terms of systems, people, roles, manuals, rule books etc. It is not that the ‘process’ stays the same and the ‘rules’ change. Some rules are volatile; some hardly change. Sometimes the physical implementation stays unchanged for a long time. This could be simply because it works; or because it would be too expensive or disruptive to change it; or because no one thought of changing it. Sometimes – particularly for cost and/or quality (and therefore competition) reasons – the physical implementation has to change.

To show how artificial it is to separate ‘process’ from ‘rule’ consider a familiar administration process. There could be a rule that a particular document or data item must be available. What if it is missing? We do not suddenly move out of the ‘rule’ domain (‘x is needed’) into a ‘process’ domain – where we would learn how to get the missing information. The stipulation that the information is required is a rule; and the statement of where to get the information from is also a rule. We could envisage an implementation where on finding the information is missing the requirement rule immediately leads to generating correspondence to request the outstanding information from the intended recipient. This is process, but it is also rules.

To return to the process meta-model, to talk of rules not satisfied means we should qualify the statement that the outcome is precisely the thing requested. Yes the request is for the outcome in that, for example, an application (request) for a passport is an application for a passport (outcome). But not every passport application leads to a passport. There are eligibility rules, and if the applicant cannot for example produce a birth certificate proving place of birth the passport will not be granted. Strictly speaking the outcome is not necessarily a passport, but a well-formed result in line with passport application rules. The paradigm ‘well-formed outcome’ will be a passport. But because it must be possible for rules to be not satisfied, the actual outcome may not be the requested outcome.

Far from refuting the model this is actually a crucial implication. Exceptions and error conditions are the bread and butter of business process, because rules are.

So what are rules? We have said a lot about them but not yet tried to define them. This was deliberate. The meta-model only needs an operational definition: something is a rule if it is used as a rule. This is almost circular but not quite. It reflects the same thread of intentionality as ‘request’ does.

This may be yet more heresy to business rule theorists. I have no quarrel with the view that a significant subset of business rules may best be expressed declaratively – perhaps in a predicate calculus – and be categorised into ‘rejectors’, ‘projectors’ and ‘producers’. For rules like these it may well be true that

…rules build on facts, and facts build on concepts as expressed by terms.

[Ronald G. Ross (2003)4]

But I am unconvinced that there is anything about ‘first, take the order, then check the order, then check credit rating…’ which disqualifies it as a statement of rules. The development of systems and therefore the implementation of business processes may be facilitated by a specially designed ‘logicbase’ (consisting of a ‘factbase’ plus a ‘rulebase’) whose contents conform to rules about format, atomicity etc. But this assumes we know what our process (our ‘script’) already is, and our intention is to make it as efficient and as flexible as possible by providing optimised support and guidance from an optimised store of rules. This is fine as long as the script itself is optimal. But if it is not how do we know? Because it is more expensive or slower than our competitors’? Because its error rate is higher? Because it is therefore not ‘best practice’? But this may only focus on how the script is followed, not on the script itself. Where does the script come from? As soon as we ask that question we open ourselves to possible ways of analysing the process itself; and I suggest that a helpful way to do this is in terms of rules, without presupposing any criteria as to what a ‘rule’ is, other than its being used as a rule.

There are many reasons a statement (typically in imperative or indicative mood) may be used as a rule. It could be an internal fact about the organisation or a fact about the universe beyond the organisation. It could be something true by definition or something the organisation or some other body wants to hold true by definition. It could be a control the organisation wants in place, temporarily or permanently, to mitigate risk, to ensure survival or compliance, to monitor or maintain or improve its competitive position or its quality or its profitability. And so on.

Many rules will be reasons why current implemented processes are how they are. Some rules may be better implemented (now or in future) if the processes were different. Some processes may be how they are because the rules are believed to be what they are. Some explicit or implicit rules may no longer make sense or may never have made sense.

Clearly the intention should be – at least ideally, and assuming the opportunity exists – to establish what the rules are and should be, regardless of what is actually taking place in the organisation, including everything that is or should be used as a rule, and excluding nothing on grounds of content or format. Then the processes can be logically defined – which is what the process meta-model demands.

Now we have shaken some of the dogma off the concept of a business rule, the next section can use it to build up the rest of the logical process meta-model.

References

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.

2 Roger T Burlton, quoted in: 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.

3 Ronald G. Ross, Do Rules Decompose to Processes or Vice Versa?, Business Rules Journal, Vol. 4, No. 12 (Dec. 2003), URL: http://www.brcommunity.com/b155.php.

4 Ronald G. Ross, Principles of the Business Rule Approach, Addison Wesley Professional, Boston, MA, 2003.

© Chris Lawrence 2008

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: