The SourceXchange model is pretty intricate, and only yesterday did I realize that the
original mess I drew didn't work out because I was trying to model several processes in a
There are three processes in a SourceXchange project. The first is the overall SourceXchange
process, as follows:
The signoff process, invoked for each completed milestone, is as follows:
- Proposer selects an RFP and writes a proposal, and submits it to the Sponsor.
- Sponsor accepts proposal
Obviously if the proposal isn't accepted, nothing else happens.
Note that this effectively means a moribund process.
- Proposer creates a project plan, including milestones and assigns Developer
Initial milestones are technically part of the proposal, but after a formal project
plan has been developed, it's likely that the milestones will be modified somewhat, at
least with respect to order.
- SourceXchange assigns Reviewer.
- SourceXchange sets up formal milestones
Note that the formal milestones are a simplified
version of the project plan.
- Developer(s) execute the project plan.
This is getting to be a common theme, isn't it? Create a project plan and execute the
- Upon completion of each milestone, the signoff process is executed.
Here's where it gets interesting. The signoff process, defined below, is parameterized
with respect to the milestone being signed off. This is a new twist.
- When all milestones are complete, Sponsor and Reviewer review the finished product
and accept it.
- SourceXchange makes the code available onsite.
(2/21/00) XML process definition here.
- Developer announces milestone
- Sponsor and Reviewer review milestone.
If the sponsor refuses the milestone, but the milestone is accepted by the Reviewer, then
something very odd happens. The current signoff subprocess runs to completion, but the
main process, the parent's parent process, is aborted! This requires a formal exception model
and the facilities to define exception handling.
- SourceXchange pays Proposer
Complex compound process
So we have three process definitions here which interact in a rather complex way: the main
process, the project plan subprocess, and the signoff process. Each task in the project
plan, then, effectively represents an instance of the signoff process. And this is
specified when the main process invokes the project plan.
When an exception is encountered in the signoff process (the Sponsor rejects a milestone
when the Reviewer accepts) then the main process must take action. We can very easily
consider a project-abort process as well.
The notion of a compound process, then, is a quite powerful one, especially when you throw
in the idea of parameterization.
Administration via workflow
When you consider that completion of each task in the project plan invokes the
signoff subprocess, then it starts to make sense that any action taken by the
workflow system might best be represented as a process, requiring any number of interactions
by people or programs, and notification of any number of people, recording of arbitrary
data, or whatever. This is one of the suggestions I made in my original proposal. Given
that the system is a workflow system, then any aspect of its operation should be configurable
by specification of a process. Right? So to add a user to a group, a process is potentially
invoked. To assign a user to a task, a process is invoked. Arbitrary processes may be
used to do this, or simple default processes will be used instead. Make sense?
These summaries are getting repetitive, but that's because this is the last usage scenario.
It's time to get on to the user interface and process definition DTD, and then get coding!
I think that's about it.
- Exception handling: a subsubprocess, in this case, can cause an exception in the main process.
- Parameterized invocation of processes and subprocesses.
- Completion of each task in a given process may itself be a subprocess.
- Any operation performed by the system is potentially regulated as a (sub)process. This
process may be a systemwide default, a systemwide configuration, or a process-specific
configuration, so that user assignment, for instance, may be done in one way for one
process and in another way for a different process.