BPMN vs ACM... Again

It boggles my mind that we are still having this debate, but there it is: Is BPMN compatible with ACM? The latest round started with a paper presented by Keith Swenson at a BPM conference, stirred up by Sandy Kemsley's review, and kicked into full riot by an ebizQ comment thread. The supposedly winning argument from the ACM side is that a doctor - the purported archetype of an ACM user (really?) - is never going to edit a BPMN diagram, but is willing to add or tick off items in a checklist. But this misses the point on several levels:

  • BPMN is a definition language. End users, whether they are doctors or computer scientists, are not supposed to define process logic, case logic, or any other kind of repeatable business logic. That's why we call them end users.
  • Inserting ad hoc tasks to a process or case instance at runtime is mostly a UI issue. True, BPMN is not very ad hoc-friendly, but BPMN-based tools have successfully worked around that. Oracle, for example, does it through WS-HumanTask. Roubroo does it by versioning the BPMN definition and migrating the instance automatically under the covers.
  • If ACM is only about ad hoc task management in a checklist, why are we even talking about it? Microsoft, Google, and the like basically own that space, and they can have it. The "A" in ACM is adaptive, meaning there is some defined logic that advances the case. That means that with ACM, just as with BPMN, there are definition tools and there are end user tools, related but not the same thing.
So the focus of this debate should not be whether BPMN is appropriate for the doctor, but whether it is appropriate, say, for the author of a protocol of medical tests and treatments relating to some set of symptoms. If it's just Dr House winging it, that's not really ACM. That's just ad hoc, a checklist made up on the fly. And even with less ingenious practitioners we have it already: it's called the patient chart. ACM should really be about the repeatable (and yes, extensible) logic, not just the ad hoc.

This gets closer to the real issue, which is the fundamental distinction between orchestration - what BPMN means by the term "process" - and ACM logic. What I think ACM means is a kind of goal-seeking logic, using backward chaining from the desired end state. Case activities have prerequisites, and any activity with all its prerequisites satisfied is allowed to start. Unlike orchestration, ACM can add new activities and prerequisites even after the case has started. In orchestration, the process instance must follow some explicit path defined in advance.

I haven't yet seen any examples of this goal-seeking ACM, but I hope to one day. (If you have such a thing, you definitely should be at bpmNEXT in March!) I agree this kind of ACM would be really useful in many situations where orchestration doesn't work well.

But here's the thing: This goal-seeking logic needs a definition language, ideally with some graphical representation. And I doubt that notation is going to be more business-friendly than BPMN. I suspect it requires some form of state diagram rather than an activity flow diagram, and that means it will be far less intuitive to a non-technical audience than a flowchart variant like BPMN.

Another point sometimes ignored is that a case in ACM is likely to contain structured processes (orchestrations) in addition to isolated tasks, so the ACM definition language must at least integrate with BPMN somehow. Also, BPMN already has notions of events, messages, and data stores needed for ACM as well. No one claims BPMN 2.0 is all you need for ACM - that's a ridiculous straw man - but to argue for ignoring BPMN entirely seems motivated more by commercial considerations than technical ones.