As an expert in WF, I would very much appreciate your insights into the following issues.

Enterprises rarely remain static for long. They need to continue to evolve and adapt to remain competitive. At the same time, processes in an Enterprise Workflow application may remain active for significantly long periods of time before they reach a terminal state.

How do you efficiently Evolve and Modify an Enterprise Workflow "on the fly" with some workitems still active in the previous version that must be preserved?

With Enterprise Workflows being complicated enough already, I doubt that you want to add too much duplication to achieve changes in functionality and turn the workflow quickly into the equivalent of unmanageable "spagehetti code".

Without the ability to adapt to changes in workflow "on the fly", I am afraid that WF has limited usefulness in modeling the workflow of real Enterprises.

Much of the talk of BPM and MDM speak about making the Enterprize Agile and involve Continuous Improvement. That means that the WF representing the Enterprize needs also to be Agile and Continuously Improved if it is going to represent the WF of the Enterprize over some period of time. But I don't see how that can be done easily.

In a typical scenario the WF is large and complicated representing a medium to large Enterprize. It includes many steps and checks within it. The WF is always running and should not be shut down because the Sun may never set on the Enterprize. There are many threads running simultaneously in the WF at various degrees of completion. A single thread within the WF may be active within the WF for a relatively long time, maybe many months, before it reaches completion.

Now you need to make changes to the WF fairly frequently to improve it. You need to modify the WF that is there. You need to modify states, add new checks, new paths, delete some pieces. Responsibilities and Decisions within an Enterprize change over time. The changes may be small or they may be massive in scope.

And You need to replace the working WF with the new version without shutting the previous WF down and you need to migrate the active workitems from the old workflow to the new version without losing anything. It is also possible that some of the new changes to the WF may include some of the activities or states containing one or more active workitems. The problems are much more difficult than just editting a change to the WF and the publishing the new version. The problem is more: How do you seamlessly transition from one version of an active WF that contains active workitems in partial states of completion to a new version, and how to plan and prepare for such tansitions?

Also you do not want these changes and migration of the WF to overcomplicate the WF and obscure the true purpose of the WF, or the WF will eventually collapse of its own weight and will fail to represent the true functionality of the Enterprize.

These are the things that a WF environment needs to do if the WF is going to serve an Enterprize for a significant length of time.

For example, let's take the simple case of a working WF that includes many things including the process of getting Expense Reports paid and you need to add one more Administrative check to the existing process. But the WF is already running and there are many active workitems already in the WF including Expenses Reports at various stages of completion. What is the best practices for making the needed changes to the running WF and of designing the WF beforehand to be prepared for changes like this?

So the questions are:

How do you build a WF that has Agility (ability to change and adapt quickly and easily)?
What are the best practices to use to continually improve a working WF?
How do you migrate from a working WF to a new version without shutting it down?
How do you migrate active workitems from an old WF to a new version when some of the differences may involve some of those threads?
What tools and techniques are available to assist with these types of changes to an active WF?

If Workflows do not have Agility themselves and can not be Continuously Improved, then I maintain that they can not do a good job of aiding an Enterprize that is striving for Agility and Continuous Improvement. The WF should not hold back an Enterprize from Continuous Improvement because the WF itself is difficult to adapt to changes "on the fly".

If Workflows wish to achieve the functionality within the Enterprize that they desire to represent, then the Workflow Environments must assist with an environment of Change and Continuous Improvement. How does Windows WF deal with these questions and issues?

Does it appear to you that to design Workflows to be agile and continously improved "on the fly" is a fairly difficult thing to do? Won't this inability of Workflows to handle change gracefully hinder their adoption and use in agile Enterprises?


THANKS.