The Devil Is In The Technical Details

My reply to Bruce's comment got out of hand so I decided to publish it as a separate post.

For the sake of the discussion, let's zoom in on the part where we see different things :-) I understand your point of view as focussed on the modelling side. Then you see some vendors that can take a BPMN model, add details (be it visible in the diagram or just properties) and then this model becomes executable:

"
BPMN is just the model, the activity flow in abstract sense. The implementation properties of each activity, event, or gateway are layered on by developers. Not in code, but using the visual tools even those guys like to use. And not stored in BPMN attributes, but in the tool-specific metadata that drives the executable language.
"

I doubt the general feasibility of this approach.

First, this implies that at least some visual model constructs that can be used during analysis have a runtime meaning. There are different kind of analysts. Some have a tech background and they know that this process is going to be executed on a computer system. Some don't. Analysing a business process, means trying to understand the business problem and describing that. The analyst might use all the BPMN constructs for that not knowing what that these have a runtime meaning on a computer system. An executable model is software that is to be run on one system. I think that in general, there always needs to be a human translation from the analysis model to the executable model, even if both the analysis model and the executable model can be expressed in BPMN.

With jPDL, we have focussed on modelling freedom, which means that the executable process diagram should look exactly like the analyst diagram. And that was not trivial. Important concepts are listeners (aka actions) so that a developer can associate callbacks on specific points in the process. Another concept is that the runtime behaviour for nodes doesn't have to come from a fixed set of process constructs. Instead, if the analyst has a really weird requirement in a specific node (aka activity), then the developer can code the runtime behaviour for that node in a plain programming language like java and hook it up in the process.

I think that an executable process language needs those kinds of features and a lot more to really keep the same diagram. I think it is often overlooked that analysis and implementation are two different things.

So the simple waterfall model of adding implementation details to an analysis model doesn't cut it for me.

The second part where the pure plays will keep having a problem with the development teams is embeddability. Instead of having a separate monolithic BPMS that has to be connected to applications, I have seen that the developer community likes it much more when the BPMS logic can be embedded into their own applications. And the BPMS database can be a set of tables right next to the application tables. That is what the operators like: Since the BPMS is part of the application, it reduces the number of systems that need to be managed and hence simplifies IT operations.

To support embeddability, BPMS vendors like us need to support all the DB's out there. Next, the application domain model needs to be coupled seamlessly with the process executions. E.g. the Order hibernate entity (or ejb), needs to be linked bidirectionally with the Order process. That is something that we can offer on a API level basis to developers.

I didn't yet see another executable process language then jPDL that can offer that level of convenience to the developers. IMO, it is not possible to get this level of convenience for developers if you start from the analysis model. Somewhere you have to turn requirements into a software design.

Without this translation idea, in all other executable BPMS systems I have seen so far, executable details ripple through in the tools offered to the analyst. And in the niche markets where those vendors are active now, a lot of analysts have some technical background. But if we want to make BPM and workflow a ubiquitous technology that is in the repertoire of every IT team, we have offer it in a way that is easily consumable for IT teams.

One last parting thought, inspired by the vendors that you reference. What do these vendors have different then what Ultimus had 5 years ago ? That was the first vendor I looked at when I started. At that time, they already had a very complete product. How come they (and so many others in that field at that time) were not able to gain any significant market share. Instead it seems like BPM vendors come and go all the time. None of those is able to get beyond a certain treshold of adoption. I think this has to do with the fact that BPMS tools sell easy to CXO's, but it is very hard to make a BPMS that is attractive to developers. IMO, it's the IT team that should select a BPMS, not management.

Thanks Bruce, with this awsome discussion, it certainly got out the best in me :-)