In contrast to open-source projects, which consist of many small changes, closed-source
projects (in my experience) are characterized by many requests rolled into a single large
release. The general way this happens is as follows, really:
- Users request changes or identify bugs for some time.
- At some point, an analyst selects a number of change requests and says those requests
will make it into the next release.
- The analyst creates a project plan for achieving the release.
- Developers execute the project plan.
- For each change completed, there are certain tasks to be done: unit test, integration
test, regular builds, and so forth.
- After development, the new release is deployed.
(2/21/00) XML process definition here.
There are two things about this scenario that differ from the previous ones so far: first,
we're talking about several workflow processes in an integrated system, and second, the
step "execute the project plan" is exactly an ad-hoc process and beautifully
supported by the notion of a compound process. The cool thing being that the subprocess to
be executed is itself a deliverable of an earlier step.
Multiple workflow processes in an integrated system
OK, we've talked about this idea already, it's true, in the open-source usage scenario. But
this is a little more complicated. For instance, one process is the bug submission process.
The user notes a bug, somebody gets notified and checks it out, and a change request may or
may not be created in the database. Another is the release planning process, which is really
the main process in this outline. Another is the unit change approval process: the developer
signals completion, testing is done by another department, the test plan might be changed,
and after acceptance, that task in the subprocess "execute project plan" is considered
complete, at which point the engine determines which task(s) come next.
My point in all this is that the processes must be aware of one another, must be bound to
one another and capable of affecting one another. A sufficient mechanism for this would be
a set of functions available to process definitions which would provide the functions
mentioned in the open-source scenario.
Ad-hoc compound processes
The problem here that I had originally was that the project plan is a deliverable and
a subprocess definition. But Thomas's idea of multiple repositories for scalability also
solves this problem neatly: if the deliverable repository is made available as an alternate
process definition repository, then it's easy to see that when it's time to execute the
project plan, we just copy the current version of the deliverable and start executing.
This was originally the first of my scenarios which showed a compound process, and at the
time it was quite mind-blowing. Of course, Anthony had anticipated me, so now it doesn't
look as astounding. Ah well.
Summary
- Processes exist in a system of processes. Processes must have facilities to affect one
another. (Already covered in the open-source scenario.)
- The definition of a subprocess may be a deliverable of an earlier task in the current
process. This is best served by allowing the deliverable repository function as a
"remote" process definition repository.
|
