- Using Workflow
- Characteristics of Web Development
- Virtual Assembly Line
- Workflow Concepts
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Workflow Concepts
Now that we've seen some of the benefits of a workflow solution, let's look at the concepts behind designing and building a workflow.
Interaction Pattern
The basic premise behind the workflow paradigm is that the process of developing web assets consists of frequently repeated interaction patterns between people, projects, and the business. For example, it is very typical for a web development group to need a way to track small or medium-size changes to a web site. For instance, someone discovers a misspelling in a block of text, a contact address changes, an outside party objects to the appearance of an image, or HTML code is found to be incompatible with a particular version of a browser.
On the surface, each such change is simple to handle. The change itself requires a simple edit to a graphic or to a text file. Getting it reviewed and approved takes only a minute or so. Moving the change into production entails copying a handful of files. But the volume and frequency of the changes means that the process is far from simple. Difficulty comes from the interaction from juggling many changes simultaneously. As contributors juggle more projects, the coordination overhead increases. Idle time on a project outweighs the work-time, dragging down throughput.
One key to success is to isolate each change into a workarea, to minimize the interactions between changes when the individual edits are done and to facilitate testing. A workarea provides the context in which the changes will be made. In the virtual assembly line, the workarea is the work cell that circulates among the collaborators. Joining in at the appropriate time, each participant in a virtual assembly line sees the work of the others.
The next step is to identify a frequently repeated pattern of interaction between developers. The exact people might vary, and the precise assets involved might vary, but you should look for a pattern of repeated interaction. For instance, a web producer assigns work to the development group, someone in the group volunteers to take the assignment, the developer hands off the work to a reviewer, and the reviewer hands it back to the producer. That is a pattern. Focus on the task that each person performs and the hand-off to the next person. After a pattern is identified, represent the interaction as a related set of tasks.
Tasks
A task represents an activity. Table 1 shows the possible kinds of tasks.
Table 1 A Workflow Job Is Composed of Tasks
Job
Our goal is to define a workflow job specification, which codifies the sequencing and dependencies of the interactions as a collection of workflow tasks. A workflow job specification is a program that creates an instance of a workflow job. We call an instance of a workflow job specification a job. The workflow job specification usually presents a user interface with which to solicit additional details about the job. For example, when Dana creates a workflow job for her Olympics memorabilia page, the program asks her for a description of the tasks, the group that should receive the assignment, the person who should review the work, deadlines for the project, and other pertinent details. The program may also access a database or a configuration file for permissions or email addresses. The program uses these inputs to specify the tasks that constitute this instance of the workflow.
Transition Link
A job consists of tasks that are connected to one another by transition links. Transition links define how the completion of one task activates one or more successor tasks, and appear as the arrows between the task boxes in Figure 4.
){kind=link}
Active and Inactive Tasks
A task is either active or inactive. When a job is created, all of its tasks are inactive, except for one or more designated start tasks. The state of a workflow is determined by the active tasks. For example, if a user task is active, that means that the job waits for the assigned person to perform the desired task. When an active task completes, a transition occurs to another task, which then becomes active. If there is exactly one transition link to another task, then the transition is unconditional. If there are two or more transition links, then the user or some other conditional logic chooses which other task or tasks to transition to.
Building a Workflow
Let's describe how to codify the pattern of interaction into a workflow. Figure 4 shows a simple arrangement of tasks for a bare bones workflow. There are three tasks. The job starts at a group task, which we refer to as "Edit." A group task allows anyone in a certain group to volunteer to complete the task. After editing by that person is complete, the task unconditionally transitions to a user task, which we've named, "Review." If the reviewer chooses the "Approve" transition, the link takes the job to the "Done" task, which completes the job. If the reviewer chooses the "Reject" transition, the state goes back to the "Edit" task.
Figure 4 A simple arrangement of tasks for a workflow.
This example shows how a job can be composed of different kinds of tasks, and shows the different roles that the task types play. For example, the group task allows any member of a group to volunteer to take ownership of a task. This example also shows how some situations use an unconditional transition to a next task, and it shows where it makes sense to have a choice of transitions. The review task that has a choice of "Approve" or "Reject" is an example of a conditional transition.
When a job is created, the tasks and relationships between tasks are specified. Details include such things as who is assigned the task, which task precedes another, or which files are being modified. Some aspects of the job are fixed at the time the workflow is instantiated, but others can be changed after instantiation. For example, is the reviewer assigned to the "Review" task known when the job is instantiated? For some organizations, the answer is "yes" because there is one designated reviewer for all work done by a given group. For another organization, the answer is "no" because the reviewer isn't known in advance. Perhaps the person doing the "Edit" task is best suited to choose the reviewer. There is no unequivocal right or wrong answer; the choice is best made by the organization. To the workflow designer, this question is important because it affects the design of the workflow job specification.
Notification
Figure 5 shows the same workflow augmented with external tasks to implement notification of relevant personnel. Recall that when many people are involved, it is important to minimize wait-time when work is handed off from one person to another. Whether notification is implemented by email, pager, or other scheme, the effect is to make sure that the job proceeds as if on a virtual assembly line. A physical assembly line in a manufacturing facility uses arrival of a partially completed unit to notify the worker at the next assembly station. In contrast, notification plays a critical role in a virtual assembly line precisely because successive steps are usually separated.
){kind=link}
Figure 5 A workflow augmented with external tasks provides notification.