What is a workflow system? [closed]

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.

Answer 2

A workflow management system pushes users through a process that hops across more than one function within a system and potentially more than one participant in the workflow. The workflow engine knows about the state of the process, and stashes this in its own storage, which may or may not be a part of the main application database.

Workflows can be modelled using state machines, petri nets or various other constructs, including plain old scripting languages. An independent orchestration system can be used to manage workflows across multiple applications. Many (but not all) support BPEL (Business Process Execution Language) as a standard description language for workflows. If your applications are set up as a service-oriented architecture the workflow system can control the application functionality to do this. The other feature of a workflow engine is that it should be possible to abort the workflow and undo any state changes while maintaining database consistency.

www.workflowpatterns.com has a collection of documents about workflow systems, along with a library of patterns.

Examples of applications for workflow systems:

• Insurance Claims Administration. Essentially the grand-daddy of them all. Typically this process will have rules covering who can authorise how much, who can process claims on different classes of business, what documents need to be present and linked to provide an audit trail, issuing and tracking the issue of payments and authorising loss-adjustment work. A typical claims workflow would track a claim from notification to authorisation of reserves and payments, through to issuing the payment, with side-processes for arranging loss-adjustment work (possibly through third parties), holding payment authority until this is finished and issuing and paying loss-adjusting expenses. In practice, these processes can get quite complicated.

• Ordering, quoting and configuration management of a complex product such as a computer system.

• One unusual example was a system developed by a pharmaceutical manufacturer that tracked the approval process for a new pharmaceutical product. This also incorporated an expert system that had the regulatory framework coded in it and could pick a shortest path through the regulatory hoops. This dropped their average R&D life-cycle time to market from 9 years to 5.5 years.