Forrester's Connie Moore validates Keith's position, which isn't far from my own. Connie tells Doug Henschen in an interview last fall:
There's lots of confusion about the term [BPM]. When we do surveys about BPM and we define it as software that supports cross-functional processes that involve people and systems, the top buyers are oil and gas, utility, chemical, retail and consumer packaged goods companies. Yet when I look at the base of clients placing inquiries about BPM, it's from government, banks, insurance and financial services. The latter have been doing process automation since the early '90s and still use the term "workflow." The former are newer to the concept [and know it as] BPM, but both groups are talking about the same thing.But in fairness to the workflow-is-dead-long-live-BPM crowd, BPM did significantly enlarge the scope of the process management solution over the vision of traditional workflow vendors. Business-oriented modeling and simulation analysis, for example. Integration adapters and middleware. Business rules. KPIs and BAM. None of that was ever part of workflow. When workflow vendors added it -- as many did -- they called it BPM. I think that's fair, and not really marketing fluff.
I use the term workflow today in two different contexts: One is as a feature of BPM, meaning human task management, which is probably how most people talking about BPM today mean the term workflow. The other is as one architectural style of BPMS offerings, in contrast to the service orchestration style based on BPEL. I don't know of others using the term workflow in that context, but I think it fits.
In workflow architecture, process activities are divided into distinct types - a human task, a subprocess, an integration step, a script or business rule, etc. Each type has its own icon in the diagram and its own configuration dialog, all of which generally simplifies process design. BPMS tools based on workflow architecture typically use XPDL to serialize the process definition, but the underlying execution language is actually proprietary to each offering.
Those offerings stand in contrast to the service orchestration style, what Keith calls EAI-oriented, in which there is basically just one activity type that "does" anything -- in BPEL it's called Invoke -- meaning all process activities need to expose the same interface, such as WSDL. Stateful activities where a simple WSDL doesn't work too well -- such as human tasks -- don't fit the model, so service orchestration BPMS's either ignore human tasks altogether or define some kind of task management service to manage the interaction. The fact that BPEL makes human tasks a second-class citizen in the process is what is motivating the BPEL4People proposal from IBM and SAP. See this for a deeper discussion of that. There are numerous other differences between workflow-style and orchestration-style offerings that have a lot more to do with their currently distinct target markets than with the fundamentals of their architecture. I might blog about that later, but not now.
Most BPMS pureplays are in the workflow-style camp, but would come out swinging if you called them that out loud. Most large middleware and enterprise app vendors are in the orchestration-style camp, although Fujitsu is not, and BEA, with the Fuego acquistion, is not any more. In general, workflow-style vendors are bitterly dismissive of BPEL, and vice versa, although most of that discussion is, in my view, ill-informed on both sides.
So... is workflow "back"? In one way I think it is, with the growing recognition among the orchestration-style vendors that the action today in the BPM market is focused around human work, not application integration. I think that's what motivated BEA-Fuego, why IBM and SAP are now behind BPEL4People (when they could have done human tasks in BPEL from the start), and why Oracle is putting so much into its human workflow capabilities. So, yeah, workflow is back. But just don't call it that.