Is Workflow “Back”? (Did It Ever Go Away?)

It’s good to see Workflow Management Coalition’s Keith Swenson blogging now.  Keith, whose actual livelihood is as chief architect of Fujitsu’s BPMS, has done heroic service over the years in advancing BPM standards consistent with the WfMC reference model, such as XPDL, ASAP, and others.  His recent post “Workflow is Back” reflects the irritation of many who are continually forced to watch BPM startups tout their “invention” of functionality that has existed in workflow products for over a decade, followed by lavish praise from industry analysts too young to know better.  He also notes that all major workflow offerings have long provided application integration in addition to human tasks — how could they solve real problems if they didn’t?   His major beef, though, is over vendors’ wholesale abandonment of the term workflow in favor of BPM, when there is in fact little or no distinction between them — implicitly validating the contention that “workflow failed” as a software technology.  Being an engineer, naturally he blames it on “marketing fluff.”

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.