The process modeling versus implementation debate continues:

 

Other posts in this discussion:



The clean handoff says business does modeling, IT does design, and anything that blurs that separation is inherently dangerous. (In fact, even directly creating skeleton design from the model is somewhat distasteful, but don’t worry, IT can change it later…) The collaborative vision says the line between modeling and design is a fine one and blurring rapidly. ... Ogren sums it up in one line: “The process model is the implementation.”

 

The difficulty in getting concensus in this discussion is that there are various skill levels of business people. Some just barely know how to use a word processor, while others are able to do some minimal coding.

 

As you put it nicely, we are in the "the clean-handoff vision" camp. But I don't think that the two visions are that far apart. I would like to refine our position and show where I see the touch point.

 

The clean-handoff vision doesn't imply you need IT to make it executable. Even in the clean-handoff vision you can strive for good coverage of process langauge constructs. The more constructs the better. But there is a fundamental tradeoff: A process language with a process construct for everything that a business person ever might want to express in a process diagram box will become too complex. The more coverage of the process language, the more complex it will be. The simpler the process language, the simpler the GUI will be and the lower the entry barrier for less technical business people. This implies that we are not looking for the ultimate process language. We can think of many process languages that make sense, I would even include Keith's spreadsheet as one of them.

 

So that is why it is hard to agree upon a specific process language: there is a whole range of process languages on the spectrum. A process language targetted to have non-technical business people create executable business processes will be very different from a process language that tries to have a broad coverage.

 

In my opinion, the process only 'is the implementation' in case the used process constructs are covered by the (always limited) process language. I would like to rephrase this as 'The process can always be a projection of the implementation'.

 

In this context, I see 2 features missing in most of todays BPMS solutions:

  1. Pluggability of process constructs: Most languages offer a fixed set of process constructs. The bridge to a general purpose programming language has to be natural in such a way that a developer can code the process construct if it is not available out of the box. In jBPM (based on graph oriented programming) and windows workflow foundation this is key. I see the article by Daniel Rubio on Winfows Workflow Foundation as one the first signs that this idea is being picked up.

     

    One of the nice implications is that you will have a kind of empty process engine with a default set of process constructs that come out of the box. The process constructs will be deployed in the engine in a packaged format. A process construct package includes the runtime implementation, and optionally a description of the configuration parameters, an icon, a UI form for the configuration parameters, a projection that filters the design time information from the runtime information to be used during process deployment,...

  2. Hidden actions: A developer has to be able to add technical details invisibly so that the business people can remain in control of the graphical representation of the process. This can be realized with some kind of event mechanism in which general purpose programming code can be associated with events in the process without the requirement of representing this visually.

 

OK, so here's my prediction of two movements that will be happening in the BPM arena. Please, interpret this overstatement as a challenge and motivation to write your response down :-)

 

1) The quest for the ultimate process language will be replaced with embracing a model like windows workflow foundation or graph oriented programming. These are actually models that define the interface between the process engine and the process constructs thereby making them pluggable.

 

And 2) More emphasis will be on the individual process constructs and less on complete process languages. That is much more feasible then trying to come up with a complete process language. This will result in node packages that you can drop in a kind of deployment directory in our generic engine. Once the interface between the engine and the node packages is defined clearly, this can create a similar component model as with e.g. JSF-components.

 

To conclude: I see the clean handoff vision as an extension to the collaborative vision. In the collaborative vision, business people model the process and the process is the implementation. It is certainly possible to have business people create executable processes in some scenarios. Depending on how complex your process language is (or how many simple process languages you combine), and the technical skills of your business people, the scope of this kind of process automation will vary. I subscribe to the above and see the clean-handoff as an addition. A technical developer should be able to easily integrate programming logic in case the business person cannot express an activity with the process constructs offered by the process language.

 

Comments can be posted here in the jboss forums.

 

regards, tom.