See also Work Flow Literature
People interested in workflow:
(add yourself here)
Also, see the Workflow Management Coalition site http://www.wfmc.org/ www.wfmc.org and Verve Product.
Context
Most commercial applications manage a lot of complex information. Users usually construct complex business objects by following structured dialogs. The system will compute various attributes for the user. Applications usually create these business objects with monolithic procedural code. This makes it hard to re-model the application and re-use work-flow behaviours between applications.
Solution
Manage dialog flows with a workflow framework that lets you describe an application's dialog flow in a declarative and abstract fashion. The same framework may be used to map the corresponding business objects to and from the associated workflow objects.
Example
Consider an insurance application. It must record information about the policyholder, the nature of risks to be covered and payment history. Data gathered at one stage in the policy issue process determines the type and behavior of subsequent dialogs. To encapsulate this behavior a work-flow manager object can be constructed that manages the order of dialog display and the creation and persistence of the appropriate business objects. This work-flow manager object may choose to make the dialog flow and dependency explicit through the use of a state-machine object that declares which combination of state and event causes the transition to a dependent state. Alternatively the state-machine can be made implicit in the work-flow object by having an enumerated state instance variable which is changed indirectly through invocation of public methods.
Consequences
In many applications the dialog flow is programmed directly using whatever interfaces exist to the Window management library. This imperative approach is familiar to application programmers but can lead to many problems later on in the development process. In managing the flow by reference to explicitly declared work-flow it is possible to more easily change the details of the flow without having to re-write large sections of it. Also it is possible to more easily change the interface to the user, or delegate to the user as in Operator Work Selection. For example, an application may find that the user is no longer a human but another application. If a state-machine approach has been used it will be much easier to re-write the "user" interface to support the automaton.
Known Uses
The work-flow pattern is used at a macro-level in contemporary business practice as a technique to measure and improve productivity. This pattern description advocates its use on a micro-level when developing applications to improve the application quality, longevity and usability.
See also Operator Work Selection
Could I impose upon you to provide a definition of "workflow" (not workflow-system, or workflow-automation, just "workflow")? What exactly is it that is flowing? Is it work artifacts? work effort? work changes? work knowledge? work responsibility? or is it the ever vague "all of the above?"
When I think "work flow" I think of systems like Remedy's Action Request System and such. Is that the meaning used here? Also, "workflow" used with "dialog" flow, raises visions of conversational mode (or at least modal) system interaction - which I've always viewed as a Bad Thing. What am I missing? -- Jim Russell
Modal can be good. In many systems is good to have a modal conversation, or a state-aware conversation, although the interface should be amodal.
Consider a task management system in a software development company. Its workflow is about tasks. It has the states: requested, assigned, executed, tested, accepted. The following transitions are possible: requested->assigned, assigned->requested (a refusal to do something), assigned->executed, executed->tested, tested->assigned (failed the test), tested->accepted.
Now, if you implement it really well, one could add a new state, let's say "need explanation" and new transitions "assigned->need explanation" , "need explanation->assigned" later, without any or with very few programming effort.
Some people can complain that the workflow is too strict. This is a problem or not, depending if you wanted, or not, to enforce dialog rules. Many companies actually need some organization to streamline the process, while I have to admit other companies need flexible processes. As an example, once I was modeling a non-workflow system that had some workflows hard-coded. A lot of time was invested to discover how a specific process worked, because it involved large sums of money and was very flexible. Meanwhile, we discovered that this specific process only happened 3 or 4 times in 10 years, while other processes were occurring many times a week. So we took out the process that needed flexibility from the scope of the system and everything went fine.
One should be aware that this is not a basic Pattern, but actually a very difficult thing to implement well and in a generalized way. I would be very afraid, for example, to do my first application work for a workflow system, mainly because I would know very little about how the processes of the domain generalize.
You would need a good theoretical background also. you should understand fully State Machines, or better, Petri Nets, to model your Work Flows.
I'm not sure anything "flows" in a workflow, exactly, as it's sort of a metaphor. What happens is that there is a whole web of tasks needed to produce an outcome, say, a signed insurance policy. The order of those tasks will depend on external influences, and there is not just one single ordering or task set that will produce the result. So, the "flow" is a flow of attention among this set of tasks. There is also a slow accumulation of information leading up to the making of a contract. This may be thought of as a kind of data flow. Mary Shaw and others coined the term "data ooze" for this kind of system, and called it an Architectural Style.
One of the reasons for having such a system is so the users can ask "What should we do next?", when the answer may not be simple. There is much similarity to managing a project with a work breakdown, including periodic replanning of the project tasks. The same fluidity is needed, hence the term "flow". -- Walden Mathews
Regarding your ooze comment, Kontinuum by web and flo actually does ooze. You get to see graphically and in an animated fashion the process ooze across your petri net. You can check it out at www.webandflo.com 
.
A Work Flow is very general concept describing how to model a process.
Something must flow. Usually you should model separately information flow and material flow. Most of the time, computer systems only model information flow and it physical counter-part, document flow.
If nothing flows, what the process is doing. If a processor (usually a person) changes nothing, adds nothing and reads nothings, it should not be in the process.
There is a site specifically about patterns that occur in workflow systems (tmitwww.tm.tue.nl ) which is maintained by Wil van der Aalst, Bartek Kiepuszewski, Arthur ter Hofstede, and Alistair Barros. It takes a view that is strongly based on the theory of Petri Nets, but it is fairly readable without any detailed knowledge of that field. -- Olaf Kummer
I've found the writings of Ilia Bider interesting in this regard. For example see www.ibissoft.com
He introduces the idea of State Flow which is one way to organize work flow.
-- Bill Hamaker
So what is a "workflow engine component" ?
See www.bpmg.org for a tabulation of the differences in software solutions for the two target markets.
See also: Architectural Pattern
See original on c2.com