I, Process, take thee, Decision..

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:

Process and Decision BPMNext slide

Slide from the BPMNext event showing the ‘simplification’ of a process using decision modelling

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

BPMN process model showing eligibility decision

Simplified BPMN process model for a bank account application, showing a business rule task to determine eligibility

TDM Decision View for Bank Account Eligibility

Decision View for ‘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.

6 thoughts on “I, Process, take thee, Decision..

  1. Right on, Nick! The irony of this silly taunt (based on the ‘proof’ of a single slide) is that in most of the accounts in which we have introduced The Decision Model, we have either introduced the client to process modeling, or have helped the client build formal process modeling into their requirements practices. Our training teaches that you cannot do decision modeling unless you do process modeling (the obverse also remains true, though perhaps that’s what these particular ‘peeps’ are peeping at!)

  2. Nick, great post. I think that you (and Larry, in the comments) have taken my tweet out of context and a bit too seriously — hard to bundle up all the issues in less than 140 characters. Although I come from the process side, I’ve long been presenting on the necessity of bringing together process and decisions, as far back at the 2007 Business Rules Forum (now Building Business Capability): http://www.slideshare.net/skemsley/business-process-management-business-rules-and-business-intelligence. I’ve also done some webinars on process and decisioning, such as this one on predictive process analytics and how they can feed back into decisions for more intelligence, self-modifying processes: http://www.column2.com/2010/07/webinar-on-process-intelligence-and-predictive-analytics/

    My tweet came from a joke that I have commonly used when presenting on this topic that poked fun at those that maintain the separation, which is probably exactly the opposite meaning that you attributed to it. The smiley at the end was the tip-off.

    Although I don’t think that analysts should be separated into those that “do process” and those that “do decisions/rules”, in many cases that’s what ends up happening because of the separate toolsets and associated skills. In fact, I have had customers tell me that they first separate projects into “process” or “rules” to decide which technology to apply, but never combine them — I tried to dissuade them of that notion after I picked my jaw up off the floor. Most full-featured BPM suites today include some degree of rules/decisioning capability, from simple in-line rules up to full decision services, which I believe is driving the two formerly-separate disciplines into a more unified practice. Certainly, any competent analyst needs to be well-versed in both, but in these times of model-driven development, they may also end up having to make technology decisions about whether something is implemented as a decision service or through process flow logic.

    • Hi Sandy,

      First off, thanks for taking the time to post a response, I really appreciate it! I’m actually relieved, in a somewhat perverse way, that I took it out of context! But on a more seriousness note, I think it acted as a suitable trigger to articulate something that’s been churning in my mind for a long time now.

      I know where you’re coming from with regards those people that essentially have technological choices to make and how that can guide them down a certain route, whether that’s the best holistic solution or not. I have another theory that people’s desire to have one method/solution be a wholesale replacement for another may come down to the Homer Simpson view of “every time I learn something new, it pushes something old out of my brain”. One of the most frequent challenges I come across when advocating any new way of working is, “I’ve got the day job, I haven’t got time”. The fact that a one-stop shop may not be the most efficient way to facilitate delivery and ongoing support doesn’t always sit well and can obviously require a great deal more investment. The integration of multiple technologies is obviously another complicating factor; it’s hard enough to introduce one new tool into most IT departments let alone two!


  3. Nick (and Larry and Sandy)

    Thanks for the post and the replies. I think the fact that processes can contain rules (about escalation, routing etc) combined with support for limited rule processing in BPMS (as Sandy notes) adds to the confusion. Process rules are not the same as decisions (or the rules that define those decisions) and the value of identifying and modeling decisions is also that it makes this separation more clear.

    Process-only approaches and rule-only approaches both have their challenges and I think the emerging standard approach using process models/decision models should make a big difference.


    • Hi James,

      I’m honoured to have so many big names of the decision management and process world comment on the post! Thanks for responding.

      It’s an interesting distinction that you make about the separation of process rules from decisions; it’s not one that I’d previously considered as a possible source for confusion. I suspect part of that is because I’ve been working with the BPMN spec for long enough that the distinction around the behaviour of gateways and the triggers for boundary events etc versus the behaviour of the business rule task is clear but, on reflection, there are a number of nuances that need careful articulation to newbies of a conjoined approach.

      It would definitely be a good thing to see the standard bridge this divide.


  4. Pingback: Deconstructing a BA job advert « Declan Chellar: Analysis Fu

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 )

Google+ photo

You are commenting using your Google+ 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 )

Connecting to %s