The simple workflow I came up with as something exemplifying an open-source project is
oriented toward bug fixes and patches rather than a big release all at once. Given the
roles Requester, Analyst, Developer, Tester, and Documentation writer, consider the
following workflow:
- Requester fills out a form and requests a change (either bug fix or enhancement request).
- Analyst studies the request and categorizes it.
- Developer makes the change.
- Tester tests the change in isolation and in the system (regression testing, whatever).
- Documenter makes necessary changes to documentation.
(2/21/00) XML process definition here.
As most people can tell you, this is already more organized than many projects. (If only
every project had a documenter!) The flow is very linear, so there's not much point in
drawing it: it simply goes from one step to the next, and no step may be completed before
the previous step is finished. Very simple but it brings up some interesting questions
nonetheless.
Notification
As more people become involved in the change (the project) then more people need to be
notified as to progress. It would be useful in this case, for instance, for the documenter
to receive all notifications as soon as the documenter has been assigned. My original
paper RAD for this workflow show notification boxes going everywhere. It doesn't always
make sense to have to specify notification; in this case, it's useful to consider each
member of the project group as being in a mailing list as soon as they join. Then
notifications simply go to the list.
Other messaging
The original RFP does mention something about message archiving, if I recall correctly
(although I may have made that up in my head). During such a project, there will be
considerable back-and-forth between analyst and developer, analyst and requester, developer
and requester, and so forth. Again, I could set those up as explicit negotiation paths,
but it makes more sense to include this sort of thing in a list as well. The conclusion
would seem to be that workflow engines would benefit from including mailing list facilities.
Certainly there needs to be some way for mailings to be archived. This could be as simple
as including an archival daemon in the mailing list so that messages are saved. I would
think the deliverable repository would be the most appropriate place to store archived
messages (including negotiations.)
Process environment
A more important insight I had while putting this scenario together is: what happens if the
analyst gets two request which are essentially the same change? Or what if a naive
requester puts two changes into one request? In the first case, it makes sense for the
two processes to be merged, and in the second it makes sense for the single process to be
split into two processes.
More generally, processes need to be understood to be running in the greater context of
a workflow system. Processes may need to interact in more sophisticated ways (although
I'm not sure exactly how yet.) Certainly the following relationships between processes
must exist:
- Processes must be able to merge
- A process must be able to split
- A process must be able to initiate another process
This is just logical. At some point in a process, some state may hold which triggers
the initiation of a second process. In this case, the first process then continues
normally. I can't think of many good examples yet: one might be that too great a delay
in the completion of a task may trigger an administrative review process.
- A single task in a process must be able to stand for another entire subprocess
Again, this is necessary for the concept of compound processes, but we're going to see
some really interesting things along these lines.
Summary
What have we learned?
- Notification should be specifiable either on the individual task level (as an explicit
box) or in some global way across the entire process. These specifications may be
mixed in a single process.
- Some kind of message-handling system would be nice.
- Interaction between processes must be possible. Processes do not execute in a vacuum.
|
