You are defining your business processes and you need to decide: do you use a BPM System or implement your processes within your content management system? The answer is likely both. Here are some design principles you can follow to manage your business processes.

Business processes occupy center stage in most enterprises, especially as the number of processes increase. As a result, it has become essential to separate main business processes (BP) from their sub processes or Workflows (WF).

Correct separation of WF from BP helps the architect determine what systems need to be involved -- Enterprise BPM and/or WCM or ECM systems.

This article will:

  1. Explain the subtle differences between workflow and business process.
  2. Provide a use case that involves business process at enterprise levels and workflows within CMS or WCM (or other enterprise systems).
  3. Provide a solution blueprint to integrate enterprises BPMs with CMS centric workflows.

BPM vs. Workflow

Since many CMS professionals either loosely or interchangeably use the terms BP and WF, this section reviews the precise definitions and differences between them. From the definitions, this section derives the design principles that can be used to separate workflows from business processes. This section also demonstrates how to chunk them into to BPM or ECM/ WCM products to accomplish the overall business functionality.

The following two references clearly bring out the similarities and differences between “workflow” and “Business Process.” The definitions, given for these two terms in WFMC (Workflow Management Coalition), decisively clear all doubts that could rise in anyone’s mind.

WFMC defines: 

  • a business process as "A set of one or more linked procedures or activities which collectively realize a business objective or policy goal, normally within the context of an organizational structure defining functional roles and relationships."
  • a workflow as the "automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules."

In summary,

While BPM and workflow share many of the same characteristics, there are distinct differences between the two. Workflow is a part of BPM; conversely BPM is a superset of workflow. Workflow is just one way among many to implement business processes, whereas BPM is about the management of workflows. A WFMS (Work Flow Management System) controls the flow of work from one person to another. In other words, it controls the information associated with workflows in an enterprise. But a WFMS does not optimize a process. Unlike a WFMS, a BPMS provides process control and integration of different application software.

Many product vendors stretch and use the term BP where it needs to be WF and hence users also have misconception that their products’ capabilities can also scale up to enterprise level BPM.

Using the above definitions and guidelines, it is essential to separate the entire process in to a main process and several sub processes or workflows. Some of them will be implemented in enterprise BPMS -- some will be implemented within (ECM or WCM) products as workflows. Here are some guidelines to follow:

  1. Using in-built CMS workflows for ‘rudimentary’ flows is acceptable; but not for more advanced flows.
  2. Rudimentary flows may be identified as follows:
    • Workflows involve moving documents, information or tasks from one to another along as given in the two references
    • No long running threads/instances
    • Do not cut across enterprise (or systems) boundaries
    • Limited human interaction
    • Do not span multiple levels of processes; a single level process with no sub-process(es)
    • There is no manual process as a part of it; for example, a step may be “someone carries the parcel and loads it into the van"
  3. If some of the actors in the process-steps are outside the enterprise, then it is better to consider BPM for implementation, rather than to consider implementing them as workflows within ECM or WCM.
  4. If all the actors belong to same work group or work on a single content/document residing either in ECM or WCM alone, then workflow within ECM/WCM is best suited rather than enterprise BPM.
  5. If one needs to coordinate the flow of any document between various enterprise applications, then BPM is the natural choice

A Use Case Supporting BPM and Workflows

An Online news magazine company entertains news and write-ups for publishing from their readers. The readers can contribute news or analysis reports; if accepted, it will be published in their on-line magazine.

Identifying the Processes

This involves many distinct business processes and workflows and also needs an orchestration or choreography of them:

1. Author Submission Process

The reader proposes a topic and write-up for publishing to the company. The reader becomes the author since he or she has submitted a write-up for publishing.

The author interacts with the company until the proposed write-up is published. The actors here are the author and the publishing company. The author is blind to the other two processes, mentioned below, that are taking place within the publishing-company.

Both the Author and the company is involved in several steps of actions before the write-up is published. Collectively these steps can be referred as Process or Workflow. Here, the collection of steps is referred as Author-Submission.

2. Editor Approval Process

As per the magazine company’s formal process, the editorial committee of the magazine investigates, reviews and approves the proposed topic & write-up for publishing in their magazine.

The members of the editorial committee need to collaborate with each other, as well as with the chief-editor, by following a content approval processes till the content is declared for approval or otherwise.

Here, the collection of all steps involved among the editorial board members and others until it is selected for publication or otherwise, is referred to as Editor-Approval.

3. Web-Publisher Process

As a part of publishing the approved article in their on-line magazine, the approved content goes through standard workflow within web publishing team. The web publishers ensure that only an approved article goes for web publishing in their on-line news magazine.

The web-publishing members need to collaborate between themselves by following their process until the content is published in their on-line magazine.

Here, the collection of all steps involved in publishing the article is referred to as Web-Publisher.

The above use case is depicted in a diagram as given below: (Some additional steps are indicated for completeness)


Separating Business Processes from Workflows

We need to identify how the main process drives or controls the workflows for a clear implementation. As an architect, one needs to emphasize the separation-of-concern for a perfect implementation of the above process and workflows.

A natural separation seems to exist. Also, the definitions and explanations of Workflow and Business Process which we discussed above give a mechanism to separate the main process from its controlling work flows.

  1. Reader Process (Author-Submission Process) is the overall process which involves steps between the author and the publishing company. By applying the principles, “BPM is a superset of workflow “and “BPM is about the management of workflows", this process can be a Business Process. This is the main process from where other two processes (or ‘workflows’) -- Editor-Approval and the Web-Publisher -- are triggered. These two processes won’t get triggered if no one submits material for publishing. So Author-Submission (Process) controls the other two processes. Thus the principle “Unlike a WFMS, a BPMS provides process control and integration of different application software“ confirms Author-Submission is a business process while the other two processes are sub-processes or workflows.
  2. Also, the author is outside the enterprise boundary and the editorial board is within enterprise boundary; hence it is better to keep the Author-Submission as BP.
  3. By applying the principle “A WFMS controls the flow of work from one person to another,“ the Editor-Approval involving the editorial committee seems to be more of a ‘workflow’ in approving the content. Here, the ‘work’ is approving and what ‘flows’ is the document to-be-approved. Probably the ‘work’ or the content (the write-up for publishing) moves from one editor’s desk to another editor’s desk until it reaches a final approval or otherwise, by the Chief-editor.
  4. By applying the same principle mentioned above, we can conclude that the Web-Publisher is also a ‘workflow’ rather than a ‘business process.’ Here, the content to be published is the one that moves from one publisher to another until it gets finally published.

Thus we have two workflows -- Editor-Approval and the Web-Publisher. We also have one governing business process -- Author-Submission Process -- which integrates the above two workflows.

Hence the Author-Submission business process can be implemented in Enterprise BPM software. The workflow -- Editor-Approval -- can be implemented as ‘workflow’ in a Content Management System. The workflow -- Web-Publisher -- can be implemented as ‘workflow’ in WCMS product.


Summary so far:

  1. There are good design principles that can be applied to separate Workflows from Business Processes.
  2. Business Processes are better implemented in enterprise BPM solutions.
  3. Workflows are implemented in ECM or WCM products depending upon the appropriateness of it. Some guidelines are discussed.
  4. Business Process(es) can trigger workflows in these ECM or WCM products.



Solution Blueprints

So far, we have seen how to identify, separate and implement BP and WF. We also saw that BP needs to be implemented in enterprise BP Engines whereas WF can be implemented within ECM or WCM products depending upon the nature of the WF. Now let's look at some Solution Blueprints for integrating BP and ECM or WCM workflows.

There are various characteristics of interaction between BP and the WFs:

  • Scenario-1: BP needs to wait to get a response from the just then 'fired’ WF before proceeding to its next step. So BP starts a workflow and waits for the results from the WF before proceeding to next step. According to the results (or outcome) from the WF, BP may branch to next appropriate step. // An example for this is from the use case discussed above: Consider the situation when the Author-Submission process triggers Editor-Approval workflow. The BP -- Author-Submission Process -- needs to branch off as per the outcome of Editor-Approval workflow. If the submitted article is accepted, then it will trigger Web-Publisher workflow, otherwise it has to inform the author that his/her work is not selected for publishing. // In this use case, the outcome is simply ‘yes or no’; in reality, the outcome can be any combination. The architectural patterns suggested in this paper will be applicable to all situations.
  • Scenario-2: While the BP starts executing each step defined in the process, at one point, BP may ‘trigger WF. BP is not looking for any results from WF, so it can, in parallel, start executing the next step defined within it. // This is a ‘Fire and Forget’ (Technical term is “Notification”) situation, while the WF is started and being executed in parallel, the BP can continue executing its next steps. // An example for this is triggering the web-publisher workflow. The next step in -- Author-Submission -- BP can be executed without waiting for any outcome from the web-publisher workflow.

Ref [3, 4, 5] at the end of this article provide various architectural patterns for combining BPM and CMS. However, in the context of this paper, the following are the realities:

  1. We do not attempt to integrate a BPM product with CMS Product.
  2. We are trying to trigger a workflow from a Business process that is running within a BPM product. When it is triggered to start, the workflow will run within ECM or WCM product.
  3. Technically, the ‘integration between BP to WF for this purpose -- the former triggering the later -- is not dependent on whether the triggered workflow will return a specific ‘message’ (or Outcome) back to BP or not.

Any WF in CMS products such as Documentum or Filenet can be triggered through a ‘Service API’ call. (If you are above 30, you will like to refer mostly as API, and below 30, mostly as Service, is what someone told me jokingly.) It is a web service call from the BP to WF.

A typical web service call will consist of the following three main components:

  • <WF name>, /* Two work flows: One WF name for Editor Approval one more for Web Publisher */
  • <Input Parameters1…and their respective data types> and
  • <Return value and its data type>

The above three main components should be known at the point of invocation of the BP. The way of invoking the WF from BP through a web service whose details are known apriori is called a Point-To-Point Connection. The same is shown diagrammatically in the following:


The advantage is that there is adequate loose coupling between the BPM product and WCM or ECM product since the call is through web services. But it is not completely loose, as we see in the next alternative described below.

Programmatically on-the-fly, one needs to find the web service for the workflow. Usual practice is to keep all such web service details in one place, possibly in a Service Directory, which in turn will be in an ESB (Enterprise Service Bus). After finding the relevant web service, again programmatically, one needs to find all the components of the web service and invoke the service.

In this case, it is known as ‘Detect and Consume’ pattern. One detects the three basic components of the web service that is relevant to the consumer. The following diagram explains this situation:


The advantage of this method is that it is a loose coupling between BPM and ECM or WCM products. Whenever the WF’s web service name or other details change, it can be reflected in the service directory and the web service call will go through without any failure. The disadvantage is that the cost of an ESB comes-in.


Web services are the best and easiest way to call and invoke workflows in ECM or WCM products. Business processes in enterprises BPM engines and workflows in various products can be integrated and correctly orchestrated through web services using one of the two suggested techniques: ‘point-to-point’ or ‘deduct and consume’.


3. 5 Things to Consider When Integrating Your CMS and Portal Products:
4. Architectural Pattern in integrating BPM and ECM:
5. Part 2 Architectural Pattern:
6. Engineering well formed Services, Sankaran Prithviraj, Hi-PC Conference, Dec, 2008,;