Business processes and business rules #1
This is the first in a series of articles adapted from a paper on Business Process Architecture and the Workflow Reference Model [Lawrence (2007)2] 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 series explores the relationship between business processes and business rules in the context of a proven business process meta-model. This meta-model is derived not from workflow or Business Process Management (BPM) technology, but by analysing what it is to be a business process.
Business process meta-model
The meta-model I want to present is fundamentally the one I described in Make work make sense.3 It is a particularly appropriate model for rule-intensive domains like financial services and administration generally – which are just the kind of areas where BPM and workflow technology predominate.
They are also areas where it is helpful to see the business process as something logically prior to any physical implementation in people, systems, organisational roles, departments and business partners. In presenting the meta-model I hope to clarify what I mean by ‘logically prior’.
To get to an effective logical model we also need to start a long way away from the system solution level: Petri Nets, functional decomposition, rules engines, interoperability, choreography, message exchange, process fragments. We must start further back.
This is because both automation and integration call for the right representation in the right generic structures. We need a meta-model which promotes the right kind of rigour.
We should see the business process first of all as a what – something which can be implemented in a how. Then we can represent the business process as a business process, not as a piece of automated machinery – even though we may well want to implement it as automated machinery.
Business Process Modeling Notation (BPMN)
But first a word on Business Process Modeling Notation (BPMN), which is fast becoming a process modelling standard. All the diagrams in this series are in BPMN. But just depicting a process in BPMN won’t automatically turn it into an optimised and logically structured model at the what level.
In fact we most frequently find BPMN operating at the how level, at the level of the ‘as-is’ or ‘to-be’ implemented process, rather than the logical, what, level. For example contextualising a process with pools and lanes is most relevant once the physical implementation, the how, has been decided.
Luckily though BPMN is methodologically agnostic:
BPMN is independent of any specific process modeling methodology.
[Stephen A. White (2004)4]
And thankfully there is little to prevent it being used to depict business processes at the logical level – as I hope my diagrams will show.
Request and outcome
We start with a familiar schema:
input ⇒ process ⇒ output
Process re-engineering and quality initiatives often assume a model like this – implicitly or explicitly. The model is not false, but it is too generic. It can apply to a natural process like photosynthesis or a computer system process like computation. It says nothing specific about business processes.
We can express this by making the first and last components more specific:
request ⇒ process ⇒ outcome
There may be other inputs and outputs. But what makes a process a business process is that it is initiated by an implicit or explicit request. In the paradigm case the request is explicit, from an external customer. But the request could be implicit, and the customer could be internal rather than external. Where goods are manufactured and/or distributed for stock, the request itself is pre-empted. But even if the request lies in the future, it is still the reason the process exists.
The ‘customer’ could even be a supplier who perhaps asks an actual or potential customer to ‘supply’ a new contract, transaction breakdown, or overdue payment. We need to construe ‘customer’ very broadly, as any entity likely to ‘request’ something the ‘supplier’ might agree to provide. Ultimately the initiating event is described as a ‘request’ to highlight the intentionality which is what a business process is all about. The initiating event is a request which the ‘supplier’ intentionally acknowledges and responds to as a request.
Specifying ‘outcome‘ rather than ‘output‘ reflects the continuity of this thread of intentionality. In the input-process-output model there is no necessary identity between input and output. The process takes in one or more inputs, transforms and/or uses them, and generates one or more outputs which may be different from the inputs. But in the request-process-outcome model the request and outcome are in an important sense the same. The request is for the outcome; the outcome is the thing requested.
This may seem an over-complex way of stating the obvious. But it has architectural implications. A business process does not just happen. Nor is it just a series of causally related events like photosynthesis. It is a structured and intentional response triggered by something both intended and acknowledged as a request for a specific outcome. The request initiates the process, and in the middle of the process the request is still there. Some steps will have taken place in order to meet the request, but some will not yet have happened. So the request is at a particular status, reflecting where it is in the process. At the end of the process comes the last status change, which realises the outcome. The request is a structural element of the process.
This structural feature is evident in financial services or government administration – but it is also obvious in something as familiar as purchase order processing. A purchase order is a paradigm case of ‘request’. It initiates the process and then travels through it. The ‘order’ is not just a paper document, or its digitised image. It is the request entity itself – a dataset of request parameters: who the order is from; when it arrived; what it is for; etc.
In a life assurance new business process the request entity is the application or proposal. In an insurance claim process it is the claim. Either of these may or may not be on a physical paper form, which may or may not then be digitised.
Having identified the request entity the next step is straightforward. This is to define the rules at a logical level, including rules specifying the sequence in which the other rules should be applied. A typical sequence might be:
First: rules about what is and is not a well-formed request. Until these rules have been met it may not be clear what type of request it is, and therefore what type of process should start.
Second: authorisation rules. Each type of request may have rules about who can initiate it and what proof is needed. For example an order may need to be on an order form signed by a known representative of a customer organisation.
Third: rules about carrying out the request.
Rules like these define the process at the logical level. At this level the process is the rules. A diagram of an order process could show six steps in (eg) BPMN symbols:
But these are rules which could also be stated in words:
First, take the order.
Then, check the order.
Then, check credit rating.
Within each step will be rules prescribing how to ‘check the order’, how to ‘check credit rating’ etc. To qualify as a well-formed order it may need to be either from a known customer or, if it is from a new customer, it may need certain customer details.
‘Check credit rating’ may also include ‘IF…THEN…ELSE…’ rules, eg:
Cash with order
Pass to ‘Match against stock’
Order amount <= available credit
Pass to ‘Match against stock’
The relationship between the rules and the request entity is key. The rules must allow for every possible value of the relevant attributes of the extended dataset which the request entity defines. For example an order will have a date, a customer, and details of what is ordered. The customer will have a current available credit balance and maybe rules for calculating a discount. Each product will have a price. If the rules do not cover every possible value of every relevant attribute, the process will not cover every possible request. There could be manual and/or discretionary catch-alls, eg:
Refer to credit manager for approval
This is a perfectly sound rule, but one which needs to be unpacked to expose other rules:
How is a ‘credit manager’ identified?
What happens if approval is not granted?
Eventually the rules will be complete, when they are known to cover every possible contingency. There will be rules within rules – rules which belong inside the boxes ‘Take order’, ‘Check order’ etc.
When all the rules are completely defined, it may turn out that the high-level process flow may have to change. For example the process flow in Figure 1 may need to change to:
Here ‘Check credit rating’ and ‘Match against stock’ are in parallel, and both must complete before ‘Authorise order’ can happen. It is not that the process flow in Figure 2 is better than the one in Figure 1 – it is for the organisation to decide what its rules are.
We are only at the beginning of the meta-model but we have already begun to deviate from ‘business rules’ orthodoxy. I’ll explain what I mean in the second article in this series.
2 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. The paper is available from www.makeworkmakesense.com.
5 Derek Miers, Issues and Best Practices for the BPM and SOA Journey, Enix Consulting Limited, 2006.
© Chris Lawrence 2008