Firstly, while I very much agree that processes have value, my assertion is that any particular process is not core to the value proposition that the business is offering. The business value proposition can be derived by reducing policy statements to one or more decisions (which are in turn a collection of ‘rules’) that define a ‘state change’ on something of importance to the business – it is this state change that creates value for the business. If I then change the decision making logic as defined by this policy, I must by definition change the business value proposition itself. But if I enable the decision-making with process (a) rather than process (b), have I changed the value proposition? We have customers who offer exactly this scenario, for instance an algorithm that calculates a cost for hospital patient episodes. This algorithm uses the decisioning knowledge of the algorithm vendor within a process supplied by the hospital. Given that the actual process is unknown when the decisioning is defined, there is evidence that the process is an independent service provided to the decision module. The process is required to deliver the data to the decision module, and to respond to the decisions made, and this act of itself does have value. But there is no discretion available to the process to drive or determine the decision-making, at least in a healthy system – it must deliver exactly the right data, and it must respond correctly to the decisions made, otherwise it is not a valid process for that decision module. The alternative of creating a process and then forcing the decision logic to comply is not tenable – it is the process that is discretionary for the decisioning, not the other way around.

I understand that there is a body of practice that recommends working from the bottom up, using ‘use cases’ to identify and then describe processes, with decision making identified as part of the process meta-data. By way of contrast, using a decision centric approach, I can ask (for instance) an insurance underwriting expert how they ‘decide’ to approve an insurance application. This reliably leads to the identification of both the requisite data and the underwriting decisions that are derived from that data. And when I know the data and decisioning, I have also prescribed the process requirement to a very high degree. This does not work in reverse – I cannot infer the decision making from the process.

How would this work if we start with the process? The process will already assume some data (or not, in which case we can proceed no further) – how did the process designer determine what data was relevant? Is this data then given to the underwriter in the above example, and the underwriter told to make his underwriting decisions based on it?

Secondly, I argue that the decision centric approach reduces rather than increases complexity. The decision logic is a single unit of work, a ‘black box’ from a system perspective. The process is built to support the black-box. Neither needs to know the internal structure of the other. The complexity of the black-box is exactly as the business value proposition requires – no more, no less. This clear separation of responsibility between the owners of business policy and of business process is the key to simplifying systems – to the point where we have many customers who provide one or other as a service to implement reuse on a commercial scale. The decision makers sell expertise, and the process providers sell applied infrastructure. If the decision model is complex and requires thousand of steps and 10’s of thousands of variables to calculate a meaningful result (like the patient costing), so be it. This decisioning complexity is bounded by the business definition of the value transaction. Such a transaction cannot be processed in parts, unless the business itself sees value in the parts. For instance, if I have one decision model for the inherent vice of an insurance risk, and another for the geographic risk, does the business get any value if either of these ‘transactions’ are executed separately? Our experience suggests not – no value is derived until the insurance application is approved or rejected, and because both risk assessments must derive from the same state of the data, they must both occur within the same ‘transaction’. From my perspective the boundary of the business decisioning transaction is clear. As is the process that must support it.

I can’t agree, however, with the first comment on this thread. Mark, if you can’t agree that processes add value, I’m sure you would agree that bad process destroys value. Process is not just some valueless plumbing that doesn’t matter. Moreover, you seem to be arguing for a use of rules that increases complexity, reduces encapsulation, and makes useful abstractions difficult – I’m not sure that’s what you intended to argue, but that’s how I read comments like “So decisions (and data models) must have greater complexity to deal with multiple perspectives if they are to describe value creation. Ultimately, you need a complete model of inter-related decisions to achieve value change.”

I understand the hammer-nail problem of working in rules – everything starts to look like a rule. And that problem isn’t specific to rules, it happens with all manner of useful, generally applicable technologies. But I think that the ability to solve a particular problem with a particular technology doesn’t necessarily mean that it is the best-fit technology to solve a particular problem (otherwise we could have just stopped with assembly language and left it at that… )

2 cents
Scott

The alternative, and I see parallels with this in the above discussion, is ‘binary’ modeling. This was once promoted as a concept in data modeling but died a natural death when it became apparent that each data element needed to carry the full weight of its context as meta data if it was to be useful. The same will be true in decisioning – the model (which I believe is the thing you are looking for a name for) is more valuable than any single decision because the business needs the whole model to derive value.

This concept of decision model still doesn’t appear to have this level of paramouncy in either the discussion or the links above. A single decision implemented within a decision service is very rare – a data base with a single table is rare for the same reason – the business world does not deal in unitary concepts! It is relationships that are important, because only related things can create value (how can you create value out of a single thing unrelated to anything else). So decisions (and data models) must have greater complexity to deal with multiple perspectives if they are to describe value creation. Ultimately, you need a complete model of inter-related decisions to achieve value change. By assigning the term decision model to the equivalent of a table (a unitary concept) in data terms is going to put Business Rules terminology out of step with its peer data terminology – this would be unsustainable in my view.

We need to align decision and data concepts and their terminology because you cannot describe one without the other – data describes the business domain at rest; decisions describe the transformations in the same business domain that generate value – a static and dynamic view of the same thing that collectively describe that thing – and the ‘thing’ is business value. Processes do neither – they are merely enablers – plumbing if you like. If you change the data and/or the decisioning you must change the definition of the business value proposition itself. But any process can be used to service the domain problem – the process is not required to define anything. For this reason, commoditized generic processes are the way of the future. So I think that Bruce’s comment should be reformatted: “Integrating BPMN and decision modeling ultimately comes down to properly representing decisions and their constituent rule families in the context of BPMN subprocesses and tasks.” should be read as “Integrating BPMN and decision modeling ultimately comes down to determining the decision models that are required to create business value, and then ensuring that appropriately configured subprocesses and tasks are available to service them.”. Additional discussion on this subject can be found here: bit.ly/7S9RSx