Process Dri­ven Devel­op­ment has its advan­tages, clar­i­fy­ing implicit or already explic­itly doc­u­mented work­flows and using them as a direct base for the devel­op­ment of busi­ness soft­ware. The cus­tomers them­selves are only super­fi­cially involved in the cre­ation of the spe­cific processes, which will later be deployed at their site.

The rea­son for this is the tech­ni­cal­ity of the whole process edit­ing. While the processes them­selves can be (more or less) eas­ily  under­stood, the “get­ting there” is pretty com­pli­cated — at least with cur­rent tech­niques. There are efforts to get peo­ple from work­ing inside the processes to work­ing on the processes. This means sim­pli­fy­ing design and pro­to­typ­ing abil­i­ties of Process Design­ing Envi­ron­ments (PDE), so the cus­tomers can design and try processes for them­selves, with only so much sup­port from tech­ni­cal staff.

What level of sim­plic­ity would be needed to get IT lay­mans to start process design­ing? The processes should be sim­ple with as few syn­tac­ti­cal ele­ments as pos­si­ble, to lower the usage bar­ri­ers. More ele­ments mean more effort is needed for users to learn the mean­ing of a process. Graph­i­cal lan­guages such as BPEL are not well suited for non-technical use, because they do not hide enough of the inner work­ing of the exe­cu­tion engine. You have to know about way too many con­cepts to start design­ing processes in BPEL, which is why in gen­eral BPMN is used at design time. But even BPMN is not well suited for design­ing process at this level. Timers and events are easy to under­stand in a local con­text, but keep­ing the global con­text in mind with many processes and inter­ac­tion between them by facil­i­at­ing events and timers can be quite hard and would have to be sim­pli­fied to be of use to a non-technical user.

Another prob­lem is the data flow. Most ser­vices need to have some sort of input data to work with. But where does it come from? Which ser­vice pro­vides the data to use? To weave this kind of infor­ma­tion into the “exe­cu­tion flow”-view is hard, and in almost all cases not obvi­ous. All solu­tions that resem­ble a map­ping of data to global or (even worse for non-technicals) scoped vari­ables require the user to keep an inter­nal model of the data flow in his head. There should be some visu­al­iza­tion, but data flow analy­sis is hard and needs extra infor­ma­tion anno­tated at the ser­vices used in the process: Which vari­ables are cre­ated, mod­fied or removed?

Busi­ness processes are not com­plex though, so maybe this is a non-issue. But there has to be some pos­si­b­lity of semi-automatically pro­ce­dure to assist the user in (implic­itly) mod­el­ing the data flow in a process, maybe by analysing input vari­ables and hid­ing impos­si­ble can­di­dates, requir­ing the user to make some deci­sion, and using this infor­ma­tion later for visu­al­iza­tion purposes.

Although at the moment there is no tool (at least no tool I know…) really suit­able for non-technical users, in my opin­ion the gap is not that big. The prin­ci­ples are not fun­da­mentlly changed, they only need to be sim­pli­fied to lessen the amount of work needed to get started and the con­tex­tual tech­ni­cal infor­ma­tion a user has to keep in mind.

So, the real ques­tion remains: Would teach­ing cus­tomers to be process design­ers be worth­wile even for the cus­tomers themselves?