Models and Pasta

I was reading various posts about modeling (in the BPMN sense) and it seems to me that many of them are confusing the ability to use modeling tools to codify requirements, and the use of modeling tools to actually generate the code needed to execute the process. 

I remember that we started thinking about model driven development over 10 years ago at IBM Research. If you could only let the business analyst model the process - and then generate the actual executable from that model - what a jump in productivity and agility. It was even worked with various toy examples. The difficulty is that designing a detailed enough model of a process to generate an actual executable program required the same effort (if not more) and the same set of skills that you needed to develop the program to implement the process.  So in reality the model became a spec or requirements doc for the developers. You could imagine these models being a good way to implement agile programming for BPM - where the analysts and developers use those tools as part of an iterative development process - but alas most of their usage is closer to waterfall development than iterative development.

Take a look at the  real life BPEL diagram shown in the drool’s blog - it made the process description the worst kind of unmanagable spaghetti. Even with all the complexity shown, it isn’t even close to the most complex business process you can find out there - whether it is a human process or a business process.

So are BPMN and BPEL a step forward or backward in enterprise application development? I think they are a good way to collect initial, high-level requirements (BPMN) and as a machine readable, system independent language for business models (BPEL). Lets not fool ourselves though, as with any tool for collecting requirements - it ends being a recommendation to the developers - not a production code generator. That is unless you limit the process domain being modeled to processes that consist of a small set of simple, well-defined, recurring, easily tailorable task templates - with relatively simple control flow logic between the tasks.