I read a tweet made back in March 2013 by Sandy Kemsley, a BPM expert, after attending the BPMNext event. It claimed “proof that decision peeps are trying to reduce all processes to a single step that calls a decison :-)” and showed the following picture:
I found, over the course of the weekend, that I was getting surprisingly chewed up about what I saw as a misinformed, somewhat sensationalist, comment, which begat other misinformed opinions in response. There was talk of ‘Process peeps’ and ‘Decision peeps’ and I thought, why are analysts being segregated into two camps? The whole point of decision modelling is that it goes hand-in-hand with process modelling! The use of processes and decisions is not a binary choice and those working in the decision management field would state exactly that. The in-progress Decision Model and Notation (DMN) standard from the Object Management Group (OMG) is designed to be loosely-coupled with the Business Process Model and Notation (BPMN) standard through the use of the business rule task.
Where decision modelling fits
I’ve always been at great pains in the work I’ve done recently to underline the criticality of process modelling when working with decision modelling. Decision modelling (the-artist-formerly-known-as Business Rules, although that’s a great source of debate in itself that I don’t intend to get into) does not mean that process goes out of the window and woe betide anyone that believes that’s the case. What decision modelling can do is identify those bits of logic that are related inferentially, that is, “the act or process of deriving logical conclusions from premises known or assumed to be true” and require no sequence in order to reach that conclusion. This allows decisions to be managed as their own artefact – changes made to that inferentially-related logic may be made independent of process. So your assets relating to rules can be managed with the same degree of agility as any other asset within the organisation.
Process and decision example
If a bank wants to determine a customer’s eligibility for a current account, they will look at a number of conditions. Certain accounts may have a condition surrounding the amount of income into that account on a monthly basis. For our example, let’s assume that, in order to be eligible for a Current Account Type A, I must put £1,500 into that account each calendar month. That condition is something that the bank could choose to change at some point in the future. So for customers applying next month, let’s say the amount goes up to £1,700. Does that change the process for determining eligibility for that account? No, it’s just a variation on limit for an existing piece of information. But the key thing here is that it doesn’t change that part of the process.
The example at BPMNext shown in the photo attached to the tweet was the simplification of a process model from a series of activities and gateways to a single business rule task. That was the ‘proof’ that decision modellers were trying to simplify all process into a single step. However the proof left out the context of the example: the purpose of the example was to show that, no matter what order the activities and gateways were traversed within the process, the conclusion was the same, that is, sequence was not important. But not important in that scenario!!!!
Why process is crucial
If we look back to the definition of inference above, it says that it’s based on things that are known to be true. So the implication there is that, in order to make a decision, all of the facts are available. This is where the process is absolutely crucial. In determining my eligibility for the bank account, the data has to come from somewhere. Chances are, it may be an application form. The other likelihood is that some sort of credit check will be done. That’s probably not going to be done during the application as it requires information from an external credit referencing agency. So those two pieces of information at least have to be brought together before I can make my decision.
My drastically simplified example below shows how such a process may operate. It simplifies it by assuming that, if I am not eligible, my application will just be rejected. In practice, banks may choose to determine eligibility for a lower-grade account. Equally, I’ve not included any timeout for the send and receive response to the credit reference agency, which would probably exist and lead to some sort of exception process. It also assumes I just get informed that I’ve been accepted and ignores the actual processing required to set up the account.
I’ve also included a VERY basic decision model that shows the conditions to be evaluated during ‘Determine Customer Bank Account Type A Eligibility’.
So what does this all tell me? I can simplify the process model by including all inferentially-related logic into a call to a decision service and I build my process model in such a way that it ensures that data is available at the time the decision is required. So the application form gives me the ‘Customer Bank Account Income Monthly Amount’ and the credit reference file gives me the ‘Customer Credit Score’.
As an analyst, I’m interested in delivering the best solution for the customer; I use the appropriate things to ensure I understand what they need and then deliver that in a form that gives them greatest benefit. Decision modelling and process modelling are used when it is appropriate to use them. Decisions don’t get made outside of the context of a process (in my opinion). The two work together along with a whole other set of artefacts, like data models, user interface specs etc. There’s no ‘us and them’, because if there’s ‘us and them’, you’ve taken your eye off the ball because Mr Customer’s sat over there wondering what you’re arguing about.