The third category of enterprise software is workflow. Workflow systems model the processes that are used in the organization. From a programming perspective, a process is usually thought of as being a running program, but the processes modeled by workflow may be active for days, months, or even years; these are business processes, not system processes.
Whenever people — that is, actual human beings—must make decisions or take action during the course of a process, that process is an example of a workflow. Workflow processes can also be fully automatic, with any decisions made based on pre-set rules, but in general it's the involvement of human beings that's key.
An example of a simple workflow case would be as follows:
1. A user on the Internet submits a form.
2. The results of the form are used to add a record to a database—a situation with which you're familiar.
3. The results need to be approved, depending on the contents. A workflow system makes it easy to model an approval step:
a. After the form is submitted, it is added to a queue b. A clerk checks it to make sure it's appropriate.
Only after every step has been completed is the workflow complete. If any step doesn't succeed (the form isn't fully filled out, the clerk can't validate the data, or some other event interferes), the workflow doesn't complete, and has to be expanded to accommodate that. For instance, do you get in touch with the user (you probably want this for a business lead) or do you just discard the data (it seems many companies choose to do this with customer feedback anyway).
Between the form submission and the addition of the database record, the situation is active in the workflow system as a (workflow) process. Any time an actor is involved and must perform an action, there's a task involved. For instance, in step 3a, there is a task active for the clerk. Now consider this: "the clerk" may be a single person or any one of several people — for example, the staff of a department, or even a program that automates the validation.
In the workflow world, you talk about a role — and then you can specify, perhaps by means of an attribute value in a directory, who can fill that role in any specific case by placing that user, another process or program, into that role.
The workflow system records each event relevant to the process in the process's enactment. This includes things such as who (the actor) completed a particular task, who is assigned to a given role for the current process, and so forth.
This functionality makes workflow systems particularly useful for demonstrating compliance with regulatory requirements—a workflow system not only ensures that a documented process is followed; it enables you to demonstrate that this is actually the case.
Was this article helpful?