Work Flow

See also WorkFlowLiterature?

People interested in workflow:

Also, see the Workflow Management Coalition site [http://www.wfmc.org/] and VerveProduct.

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 OperatorWorkSelection. 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. -- WarrellHarries

See also OperatorWorkSelection

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 BadThing. What am I missing? -- JimRussell

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 StateMachines, or better, PetriNets, to model your WorkFlows.

-- GeraldoXexeo

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

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". -- WaldenMathews

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 http://www.webandflo.com/activeeye.html.

A WorkFlow 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 (http://tmitwww.tm.tue.nl/research/patterns/) 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 PetriNets, but it is fairly readable without any detailed knowledge of that field. -- OlafKummer

I've found the writings of Ilia Bider interesting in this regard. For example see http://www.ibissoft.com/english/ExpReport.htm

He introduces the idea of StateFlow which is one way to organize work flow.

-- BillHamaker

So what is a "workflow engine component" ? See http://wfmopen.sourceforge.net/

WorkFlow and BusinessProcessManagement

See http://www.bpmg.org/downloads/LookingAskance/Looking_Askance_3.pdf for a tabulation of the differences in software solutions for the two target markets.