Question

How can I differentiate a Workflow system from a normal application that automates some work? Are there any specific feature a system must have to be categorized as a workflow system?

Answer 1

Workflow systems manage objects (often logically or actual electronic replacements for documents) that have an associated state. The state of an object in the system is node in a state machine (or a Petri net).

State transitions move an object from one state to another. The transitions can be triggered by people, automated events, timers, calendars, etc. Usually the transitions represent steps in a process in the real world.

That’s pretty abstract, so consider an example: bug tracking software. A bug report probably starts out unvalidated, and as such is in a QA tester’s queue. The QA tester will validate the report and make sure the steps are clear, grade the report for severity etc., and assign it to a developer or developer group. It is then in the developer’s queue, who will ultimately fix or decide not to fix the bug, which will send it back to QA for validation. If there’s a dispute over the bug, it might go into a state in which it bubbles up the management stack.

A trivial implementation of the above is to use an enumeration for the state associated with every object, and make everybody’s inbox be a query for objects with a state of a particular enumeration value.

That’s the gist of it, but things can get more complex, such as splitting off new objects, reacting to non-human events such as timing, internal or external (i.e. third-party) services, etc.