Workflow in CMS and Beyond
Depending on who you talk to, Workflow is a core feature of a Content Management System. Many people looking for a CMS have Workflow in their selection criteria and many products calling themselves a CMS have Workflow on their feature lists. However, after experiencing workflow as a both a requirement and as a solution, I have learned that people's definition varies widely. For some products, having the most basic of approval mechanisms (two states: unpublished and published and a designated group of users that can change that state) is enough to claim workflow. At the other end of the spectrum, other products fully implement workflow standards.
The Workflow Management Coalition (WfMC) publishes a document called their Reference Model that describes workflow as "The computerised facilitation or automation of a business process, in whole or in part." This is pretty general (although I am sure there are some who would say that workflow is just about business processes and not about computers.). Workflow is commonly discussed as a set of states and transitions. A state, or "wait state," is a step in the process that requires action from external actor. A transition is an action that changes from one state to another. A workflow definition, describes a set of states and transitions and their relationships (the transitions are available from each state, the participants can initiate these transitions, and the required conditions for those transitions to happen) and also inputs and data that get captured along the way. A workflow instance is the execution of the process.
In his Server Side article The State of Workflow, Tom Baeyens describes a Workflow Management System as something "that takes as input a formal description of business processes and maintains the state of processes executions, thereby delegating activities amongst people and applications." Many CMS do not fully implement the concept of a workflow definition. What they call workflow is more of a task management system where any user can assign a task to anyone and no formal process is followed. CMS Matrix is somewhat reliable in evaluating this feature.
If you want to learn more about workflow theory, there are some excellent resources available. One of my favorites is Workflow Patterns which describes different patterns in workflow definitions along with very cool Flash movies that illustrate the behavior of the pattern. I think that patterns are useful here because they provide a language of commonly found workflow parts. So when I say something like "Synchronizing Merge", you know exactly what I am talking about. Some people will call this jargon but I think it is a good thing because it gives a shorthand way to express familiar concepts. The Workflow Patterns site also has an excellent reading list
There are many products (Open and Closed Source) which specialize solely in Workflow. These workflow engines integrate with other applications to provide workflow functionality. Most of them have a syntax (usually XML based) for defining workflows and an API that is able to receive events and trigger external processes. If you are looking at implementing a CMS only for the workflow, and your workflow is sufficiently complex and subject to change, you should consider this type of solution. Look here for a list of products. Another useful feature on the Workflow Patterns site is a page that indicates what patterns the major commercial Workflow engines support. When I get around to it, I would love to evaluate some Open Source workflow engines along these lines. Speaking of Open Source Workflow engines, here is a list of engines implemented in Java.
The industry is rich with standards especially in the area of Web Services which has the potential to coordinate workflows across application boundaries. One of the most interesting standards is XPDL which is published by WfMC. This is an XML schema that is used by several workflow engines to define workflows. The presence of a standard here means that you could theoretically port your workflow from one engine to another simply be moving a file. I emphasize theoretically here. Several workflow engines (Open Source and proprietary) use XPDL but, to my knowledge, no CMS does. It may be that XPDL is overkill for your typical CMS workflow definition.
Now that I have gotten you all excited about workflow, I would like to leave you with some very practical and sobering advice: less is more. Usually during the analysis stage of a project, workflows become very complicated. There are many factors that drive complexity: the fear of excluding stakeholders from the project, the fear of losing control, overblown promises when the project is sold, and just simply bad business process. More often then not, after painstakingly implementing complex workflows, I am asked to rip them out in favor of very simple solutions before the system is deployed because it is impossible to get anything published. Think about simplifying/streamlining/optimizing business processes before they are encoded into a workflow definition. Don't design for the most complex, infrequently used cases. Instead suggest managing these exceptional cases off line.