> On Thu, Dec 10, 2009 at 9:42 AM, sjampster <[email protected]> >> >> I agree with you that a pure statemachine which should handle the >> process you describe, will collapse on itself. The sheer amount of >> states and transitions is too big to handle. I have a lot of >> experience with this in a program of mine, and that's why I am looking >> for a better way to do things for the next version. In my current >> program a lot of feature- and customer requests have to be added >> constantly, and this has become a nightmare at this point.
As a side note, I came to appreciate this article : http://www.infoq.com/articles/seven-fallacies-of-bpm Here is my favourite quote : ---8<--- I know a lot of people will tell me that it is a process, but it is not. It is a service implementing the lifecycle of a Job Application independent of the processes and activities that may advance the state of the job application. A process is the set of activities that advance its state. Resource Lifecycles and processes are decoupled, I don't think anyone can argue with that, yet everyone is trying to model and implement processes without a clear understanding of the resource lifecycles, they are more or less "built-in" the process model. --->8--- For the sake of linking, here are two blog posts by Kenneth and me : http://www.opensourcery.co.za/2009/07/06/driving-business-processes-in-ruby/ http://jmettraux.wordpress.com/2009/07/03/state-machine-workflow-engine/ Best regards, -- John Mettraux - http://jmettraux.wordpress.com -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en
