Topic: wftk -- Usage scenarios: SourceXchange project

There are three processes in a SourceXchange project. The first is the overall SourceXchange process, as follows:

1. Proposer selects an RFP and writes a proposal, and submits it to the Sponsor.
2. Sponsor accepts proposal
   Obviously if the proposal isn't accepted, nothing else happens. Note that this effectively means a moribund process.
3. 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.
4. SourceXchange assigns Reviewer.
5. SourceXchange sets up formal milestones
   Note that the formal milestones are a simplified version of the project plan.
6. Developer(s) execute the project plan.
   This is getting to be a common theme, isn't it? Create a project plan and execute the project plan.
7. 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.
8. When all milestones are complete, Sponsor and Reviewer review the finished product and accept it.
9. SourceXchange makes the code available onsite.

1. Developer announces milestone
2. 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.
3. 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?

Summary:
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!

• 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.