BPM Arrives Into Puberty

Bruce Silver is in a real interesting discussion with Marlon Dumas. They are discussing how to synchronize the analysis model of a business process with the executable implementation of a business process.

In my opinion, most BPM Suite products are still in childhood or kindergarten, even when they may have many bells and whistles. The root cause is that most BPM products still pursue the goal of letting non technical business create executable software. The idea is that with a graphical tool, non technical business analists can graphical design a process that is executable on a BPM System. <synical>In general, it's simply not a good idea to put software, produced by a non-technical person into production.</synical> The more realistic goal is that BPM tools try to improve the communication between non technical business analyst and developers and support the development cycle of that type of software.

I have been saying for a long time that analysis and implementation cannot be unified. So it's nice to see that leading industry experts like Bruce and Marlon are coming to the same conclusions. Although they still have different ideas about the implementation parts of the equation, at least, we all seem to be acknowledging the necessary separation between analysis models and executable models of business processes:

"No one is talking about removing IT from the BPM lifecycle. In fact I even agree with your 3 roles, although I would describe their function slightly differently. The business analyst creates process models in BPMN. The solution architect (IT) makes model activities and gateways executable by configuring them via point-click dialogs and wizards (no code). The developer creates business services using Java, BPEL or whatever, which can also be bound to model activities to make them executable. The developer may be working in the SOA tool, while the business analyst and solution architect are using the BPMS."

The part where I see different is the conversions between the analysis model and the executable developer model. After an analysis model is translated into an executable process, there should be only 1 single executable process. That executable process can still be seen by the non technical people in read only mode. Consider this a projection, where the non technical view hides the the implementation details like transaction demarcations and only shows the graphical part and the business level properties and textual descriptions.

I don't think that roundtripping between the analysis model in BPMN and the executable model BPEL is feasible. It would be similar to maintaining a separate UML class diagram for the analysis of a domain model and for the implementation model. That is in practice simply not done. In my opinion, the goal should be that the executable process languages impose the least possible restrictions to make an analysis model executable.

That is the problem of using BPEL for BPM. People have started to realize that BPEL didn't deliver on all its promises. When its used as a service orchestration language to script new services as a function of other services, I didn't hear many complaints yet. But when BPEL was used for Business Process Management, that's when I heard a lot of complaints. It imposes too many restrictions and hence it's hard for an analyst that produced an BPMN analysis model to recognize the process after it has been translated to BPEL. Other languages like jPDL and XPDL are much better suited to make analysis processes executable without touching the graphical view. For one because those languages are graph based. And in the case of jPDL, an extra capability is Actions, which allow developers to add pieces of programming logic to the execution of a process without changing the diagram.

So when we (the BPM industry) would abandon the goal to let the analysts create executable software and acknowledge that, even in BPM, analysis models are different from executable implementations, then it would be a clear sign that we're moving from childhood into puberty :-)

If I recall correctly from this presentation, Neal Ford made a similar comment in general about Domain Specific Languages at his keynote in TSS Barcelona. The idea was that DSL's are there to create languages that make sense to non technical people.