BPM Acid Test (from Essential Business Process Modeling by Michael Havey, published by O'Reilly).
... BPM is suited only for
applications with an essential sense
of state or process - that is,
applications that are
process-oriented. An application
passes the BPM acid test if it is
legitimately process-oriented. The
travel agency application, for
example, passes the test because it is
best understood in terms of state of
the itinerary and is defined at all
times by how far the itinerary has
gotten. Other typical characteristics
of a process-oriented application
include the following:
From start to finish, the process
spans hours, days, weeks, months, or
more.
Because the process is long-lived, its
state is persisted to a database so
that it outlasts the server hosting it
- Bursty, sleeps most of the time -
The process spends most of its time
asleep, waiting for the next
triggering event to occur, at which
point it wakes up and performs a
flurry of activities.
- Orchestration of system or human communications -
The process is responsible for
managing and coordinating the
communications of various system or
human actors.
... For example, in an automated
teller machine, which lets users query
their account balance, withdraw cash,
deposit checks and cash, and pay bills
- any sense of process is fleeting and inessential; an ATM is an online
transaction processor, not a
process-oriented application.
Best Answer
I'm biased as well, as I am the main author of StonePath.
I have developed workflow applications for the U.S. State Department, the Geneva Centre for Humanitarian Demining, several fortune 500 clients, and most recently the Washington DC Public School System. Every time I have seen a 'workflow engine' that tried to be the one master reference for business processes, I have seen an organization fighting itself to work around the tool. This may be due to fact that these solutions have always been vendor/product driven, and then end up with a tactical team of 'consultants' constantly feeding the app... but because of this, I tend to react negatively when I hear the benefits of process-based tools that promise to 'centralize the workflow definitions in one place and make them repeatable'.
That said, I very much like Ruote - I have been following that project for some time and should I need that kind of solution, it will be the next tool I'll be willing to try. StonePath has a very different purpose than ruote - where Ruote is useful to Ruby in general, StonePath is aimed at Rails, the web framework written in Ruby. Where Ruote is about long-lived business processes and their associated definitions, StonePath is about managing State-based workflow and tasking. Frankly, I think the distinction from the outside looking in might be subtle - many times the same kinds of business processes can be represented either way - the state-and-task-based model tends to map to my mental model though.
Let me describe the highlights of a state-based workflow. In short, imagine a workflow revolving around the processing of something like a mortgage loan or a passport renewal. As the document moves 'around the office', it travels from state to state. Imagine if you are responsible for the document, and your boss asked you every few hours for a status update, and wanted a brief answer... you'd say things like "It is in data entry"... "We are checking the applicant's credentials now"... "we are awaiting quality review"... "We are done"... and so on. These are the states in a state-based workflow. We move from state to state via transitions - like "approve", "apply", kickback", "deny", and so on. these tend to be action verbs. Things like this are modeled all the time in software as a state machine.
The next part of a state/task-based workflow is the creation of tasks. A Task is a unit of work, typically with a due date and handling instructions, that connects a work item (the loan application or passport renewal, for instance), to a users "in box". Tasks can happen in parallel with each other or sequentialy, and we can create tasks automatically when we enter states, create tasks manually as people realize work needs to get done, and require tasks be complete before we can move onto a new state. All of this kind of behavior is optional, and part of the workflow definition.
The rabbit hole can go a lot deeper than this, and I wrote an article about it for Issue #4 of PragPub, the Pragmatic Programmer's Magazine. Check out the reo link above for an updated PDF of that article.
In working with StonePath the last few months, I have found that the state based model maps really well to restful web architectures - in particular, the tasks and state transitions map nicely as nested resources. Expect to see future writing from me on this subject.