Process Driven Development has its advantages, clarifying implicit or already explicitly documented workflows and using them as a direct base for the development of business software. The customers themselves are only superficially involved in the creation of the specific processes, which will later be deployed at their site.
The reason for this is the technicality of the whole process editing. While the processes themselves can be (more or less) easily understood, the “getting there” is pretty complicated — at least with current techniques. There are efforts to get people from working inside the processes to working on the processes. This means simplifying design and prototyping abilities of Process Designing Environments (PDE), so the customers can design and try processes for themselves, with only so much support from technical staff.
What level of simplicity would be needed to get IT laymans to start process designing? The processes should be simple with as few syntactical elements as possible, to lower the usage barriers. More elements mean more effort is needed for users to learn the meaning of a process. Graphical languages such as BPEL are not well suited for non-technical use, because they do not hide enough of the inner working of the execution engine. You have to know about way too many concepts to start designing processes in BPEL, which is why in general BPMN is used at design time. But even BPMN is not well suited for designing process at this level. Timers and events are easy to understand in a local context, but keeping the global context in mind with many processes and interaction between them by faciliating events and timers can be quite hard and would have to be simplified to be of use to a non-technical user.
Another problem is the data flow. Most services need to have some sort of input data to work with. But where does it come from? Which service provides the data to use? To weave this kind of information into the “execution flow”-view is hard, and in almost all cases not obvious. All solutions that resemble a mapping of data to global or (even worse for non-technicals) scoped variables require the user to keep an internal model of the data flow in his head. There should be some visualization, but data flow analysis is hard and needs extra information annotated at the services used in the process: Which variables are created, modfied or removed?
Business processes are not complex though, so maybe this is a non-issue. But there has to be some possiblity of semi-automatically procedure to assist the user in (implicitly) modeling the data flow in a process, maybe by analysing input variables and hiding impossible candidates, requiring the user to make some decision, and using this information later for visualization purposes.
Although at the moment there is no tool (at least no tool I know…) really suitable for non-technical users, in my opinion the gap is not that big. The principles are not fundamentlly changed, they only need to be simplified to lessen the amount of work needed to get started and the contextual technical information a user has to keep in mind.
So, the real question remains: Would teaching customers to be process designers be worthwile even for the customers themselves?
RSS