There was a lot of discussion of declarative models at the BPM2012 conference.  It seems that people are seeing this as a way to handle processes which can not be predicted precisely in advance.  It is worth exploring.

Let’s start with a couple of definitions (from Wikipedia):

• Imperative Programming – a programming paradigm that describes computation in terms of statements that change a program state.  Imperative programs define sequences of commands for the computer to perform.
• Declarative Programming – a programming paradigm that expresses the logic of a computation without describing its control flow. Many languages applying this style attempt to minimize or eliminate side effects by describing what the program should accomplish, rather than describing how to go about accomplishing it.

It is easy to see that traditional BPM take an imperative style.  Both Process Driver Server Integration and Human Process Management employ process models that describe the exact sequence of actions that should be done.  There is little room for experimentation or doing things out of order.

Someone at BPM 2012 described imperative modeling as: “everything is illegal except the actions explicitly allowed by the process” while declarative modeling is “everything is allowed except those actions that are explicitly prohibited by the model.”

BPMN is an imperative model that specifies what is allowed;  any deviation from the prescribed course is illegal.  In my talk on “BPMN is incompatible with ACM” (slides, review) I pointed out that when people draw a BPMN diagram, they sometimes decide to place actions in arbitrary orders.  The motivating idea behind process modeling is to come up with a process that will work given the constraints that are known at the time of modeling.  This approach specifically excludes the concern that conditions may be present at run time to dictate a different order.  If that is the case, it is a failure to understand the situation, and the process should be changed, but nevertheless the BPMN model prohibits doing the process differently than it was defined.  In many ways, you can consider BPMN models to be “over-constrained” to produce a single order of tasks, when it might be possible in business to do the tasks in several different orders.

A declarative programming style might be the answer.   A declarative style of process model would allow all actions to be take at any time, except it would restrict some actions to be take in a particular order, or only on particular conditions.  In the case management world, this would allow the case manager to handle the case in any way that is necessary, but at the same time remain consistent with the few legal or practical constraints that exist.  Clearly this would allow the case manager to optimize the individual case to the current situation.

The extreme case is a declarative model that declares nothing: everything is allowed at any time.  This is the starting point for any case management system.  Most of us can imagine cases where we would like to make sure that certain thing happen in a certain order: for example reserving a meeting room should happen before holding the meeting.  A declarative language that allowed case managers to build on past cases, and improve the constraints over time, while still being understandable might be the right thing for case managers.

Nobody at the conference presented a visual declarative programming language, and I don’t know of any.  It might be the case that the OMG CMMN effort is such a visual representation of a declarative model.  Further analysis is needed.

Clearly a declarative model could be created using a rule language: “if (conditional expression) then (manipulation of state of case)”.  There is no question that there is suitable power to do this, but the problem with large rule bases is that they are hard to understand quickly.  You have to walk through an consider each rule in order to have an understanding of how the case works.  For example, if you need an option which you have used in the past, and that option is not appearing, it may take quite a bit of debugging to find the combination of rules that are preventing the option, and it may take some careful thinking to find the right modification of those rules that do not cause unintended side effects.

I have been a fan of a simple “task list” approach, but this is not a declarative model either, because

• it implies an order (which might or might not be appropriate) and
• it does not allow for specific constraints to be expressed, such as “Task A needs to be done if the subject of the case is older than X”.

A task list is NOT a declarative model that accurately expresses what can and can not be done.  Instead, it is a simply a low-tech mnemonic device to remind the case manager about the possibilities.  It is up to the case manager to determine based on expertise and information in the case folder what the right things to do are.  Some reject this as too loose and would prefer that the case manager actions were more controlled.  However, it has the advantage that it is very useful today.

My remaining question: if a declarative modeling language is discovered, can such a declarative language be easy enough for doctors and lawyers to use directly?  It is not clear to me whether this will be possible, but we should remain vigilant looking for such a language that might be suitable for ACM.