Workflow, process, pi

Some very intelligent people are currently engaged in an intellectual equivalent of the children's game of rock/paper/scissors. In the original, rock can be defeated by wrapping it in paper, paper is easily cut by scissors, and scissors are blunted by rock. The new version pits three business computing concepts against each other: workflow, process management, and a form of algebra called pi-calculus. But the trouble with this new game is that no one can agree on the order of precedence between the three challengers.

The row was unleashed by a draft white paper issued by BPMi.org co-chair Howard Smith and business writer Peter Fingar, entitled Workflow is just a Pi process (PDF, 1.5MB). As you can see from the title, the authors believe that workflow is the lesser of the three concepts, being subsumed within process management, which is itself, they say, governed by pi-calculus.

Proponents of workflow, not surprisingly, were aghast at this suggestion. Among the ripostes was a white paper jointly authored by Jon Pyke, chair of industry group the Workflow Management Coalition (WfMC) and independent workflow expert Roger Whitehead, titled Does Better Math Lead to Better Business Processes? (PDF, 32k). In their view, business process management is just a refinement of workflow. And pi-calculus is just a branch of mathematics.

Further discussion ensued on the Workflow Research Forum in a dedicated thread. Amongst the postings are some quotes of an exchange between Howard Smith and Wil van der Aalst, a leading workflow academic, who concludes that workflow is much more than merely pi-calculus: "Workflow requires more than Pi calculus ... Pi process is a theoretical model like Petri nets, Statecharts, CCS, CSP, ACP, etc."

My thanks to Paul Brown, CEO of FiveSight Technologies, who pointed me to several of these counterblasts after noting my previous citing of the Smith/Fingar paper. Paul contributes some comments of his own in a blog posting, in particular drawing attention to the vendor bias inherent in their paper.

Personally, I feel there are weaknesses on both sides of the argument. I agree with Paul's view that customers "make selections based on the richness of the business functionality that a system provides as well as the accompanying methodology for modeling and remodeling processes." The relevance and utility of a solution is at least as important as whether it's based on pi-calculus or something else. The Smith/Fingar camp is in danger of promoting the Betamax of process management: technically elegant but a step beyond what the market is currently looking for.

On the other hand, they should be congratulated for taking a potshot at the sacred cow that is workflow, even if their aim hasn't delivered the coup de grace they may have hoped for. Workflow people seem to have a huge blindspot about its biggest flaw. The Pyke/Whitehead paper is a case in point. How is it that they can quote Webster's definition of a process — "A series of actions, motions or occurrences ..." — and then in the next line blithely reinterpret this as "a series of predefined actions ..." (my emphasis)? It is precisely because workflow is restricted to the management of predefined processes that we need to search for additional mechanisms, capable of managing processes that are unmapped in advance — which is where pi-calculus comes in.

Prof van der Aalst makes a similar slip when he poses the question, "For which workflow patterns is the notion of mobility helpful?" To ask how mobility helps workflow is to assume that workflow already covers every potential process. But the point Smith/Fingar are trying to make is that mobility is helpful precisely for those patterns where workflow runs out of steam.

The problem with the Smith/Fingar position is that they propose replacing the catch-all solution of workflow with a new catch-all solution based on pi-calculus. This is neither desirable nor necessary.

It's not desirable because accessible, functional products never stem from initiatives that focus on conceptual engineering alone. And it's not necessary because you don't need to be able to construct a mathematical model of mobility in order to construct mobile systems. In fact, the human race has, over the past several thousand years, evolved a complex global society comprising many millions of interacting autonomous agents, and yet only discovered a decade or go how to model such interactions using pi-calculus.

Hence my choice of analogy (to return to my starting point). Like rock/paper/scissors, the precedence depends on the situation. Look at it from some points of view, and it's clear that pi-calculus in some sense does govern all processes. But sometimes workflow will still do a better job. The trick is to use the right tool for the job in hand.

UPDATE [updated 3rd Dec]: A lot of thought-provoking comments have come in response to this posting over the past few days:

• Jean-Jacques Dubray of ebpml.org writes: "... the debate is actually far larger than this ... its conclusion will define or destroy SOA."


• Bob Haugen from Choreology responds: "... WfMC-style workflow models ... require all participants to pre-agree to the same predefined process, which is sort-of the polar opposite of loosely coupled."


• Ajit Kapoor adds: "... if its true that CHANGE is a certainty, then we can't have stale (pre-defined) processes to build on demand services ... why not pi-calculus to get us out of the IT prison."


• Michael zur Muehlen of Workflow Research weighs both sides: "... The WfMC ... like their processes predictable, because the involvement of pesky humans in the process creates enough uncertainty ... Pi calculus may provide part of a solution, but it has to be viewed in context ..."


• Barry Briggs responds in a detailed weblog posting: "I'm a big believer in the pi-calculus, especially as it relates to biologic systems ... however, I'm wary of overhyping it ... for real-world problems you choose the best tool to do the job. Even Milner himself is not sure of how pi relates to business processes."


• Roger Whitehead of Office Futures politely refutes my critique of workflow: "... Most modern workflow software will allow process steps to be left to human discretion. People are then free to cope with unexpected events or those with too many variables to pre-program ..."

posted by Phil Wainewright 11:00 PM (GMT) | comments | link

Semantic integration

Philip Merrick, chairman and CEO of webMethods, uses one of my favorite phrases in an InfoWorld interview published this week:

"... there’s a whole other layer to deal with, what I call the semantic integration problem. Web services are great but they standardize pure connectivity between applications. The applications still have highly varied data models, extremely different ideas of what business processes should look like. Yet for most large organizations, a business process is going to span many applications."

Semantic integration is the problem you come up against once you've done all your SOA groundwork and succeeded in linking your applications together: you discover that none of them speak the same lingo. You've integrated the technology, but you still haven't integrated what people do with it, because everyone has their own way of describing what they do.

I recently heard a great story that succinctly demonstrates the nature of this problem from Jim Green, former CTO of webMethods, who's now running a startup called Composite Software, which provides an infrastructure layer for sharing information from multiple disparate data sources. I don't know whether this was a real case or just an apocryphal story, but it comes from the pharmaceutical world, and it revolves around the language you use when your business is providing drugs. Which of these is your 'customer'?

1. The patient who takes the drug


2. The nurse who administers it


3. The doctor who prescribes it


4. The hospital that buys it


5. The insurance company that pays for it

The answer of course is all of them, depending on which application you're dealing with at any given time. So how do you automate a process that cuts across all of those applications without ending up with a pile of garbage transactions?

The answer is that you handle the semantics. I have just one quibble with Philip Merrick's choice of phrase, though. It's that 'integration' word. Integration is what people used to do, before we all discovered how much better we'll be if we aim for service interoperability within a standards-based SOA. Reading through the interview, I think it's clear that webMethods is set on moving forward, and so it's Merrick's vocabulary rather than his vision that needs to catch up. I think what he really means is 'semantic interoperability', which implies semantic interaction without loss of semantic autonomy.

A company that talks a lot about semantic interoperability is Above All Software, founded by Roger Sippl, an even more venerable software integration entrepreneur than Jim Green and Phillip Merrick. He has set up Above All Software specifically to address the market for semantic interoperability — to plug that missing gap that will still exist once enterprises have finished implementing SOA. I think it's a great market to target, one that will be huge and that will emerge and expand in unexpected ways. That's why my most favorite phrase of the moment is 'semantic interoperability'.

UPDATE [added 2nd Dec]: Several great comments on this posting over the past few days (also see the next posting for more related comments):

• James Bullock says, "Re: Who's the customer? It's worse than that. Add 'When is the customer?' ... any entity you might want to describe has a life-cycle ..."


• Ajit Kapoor writes: "... lack of semantic interoperability will render this powerful yet limited technology to transactions ... where the business semantic is first described ..."


• Rob Botman of BlanketWare concludes: "... A system that truly allows 'semantic integration', which is the place where SOA really becomes useful, must be able to process semantic relationships dynamically ..."

posted by Phil Wainewright 8:50 AM (GMT) | comments | link

Stitching up J2EE

Help us support both your platforms, or we'll write for neither. That seems to be what ISVs have been saying to IBM and BEA, resulting in yesterday's announcement of three new shared specifications. Several news outlets have covered the story:

• IBM, BEA propose Java standards — BEA CTO Scott Dietzen is quoted in this InfoWorld story saying, "Some users, and certainly ISV partners, have been instrumental in showing us the light." There's also some comment on the two vendors making this announcement outside the JCP, which governs Java standards.


• BEA Systems, IBM Team Up To Improve J2EE App Portability — CRN outlines each of the three specs and quotes some vendor URLs where more information can be found.


• IBM, BEA join on Java strategy — the focus in this CNET News.com story is very much on the politics of the collaboration between these two vendors. It quotes ZapThink's Jason Bloomberg saying "this announcement is the beginning of the end of Sun's leadership in the Java space."


• IBM, BEA Join In Pursuing New Java Specs — the new specs are designed to make Java work better in an SOA environment, according to this TechWeb story. It explains how Service Data Objects, the most significant of the trio of specs, will add a layer of abstraction that makes it easier to mix and match data from different sources.

It's interesting to see IBM and BEA going out on a limb here to announce the specs prior to submitting them to the Java Community Process (JCP), which oversees Java standards. Some observers suggest they're trying to corral Sun by acting in this way, but I suspect it's more a case of them feeling corraled by competitive forces. They're trying to force the pace towards the shared data foundation that I mentioned in an earlier posting because, if they don't, other vendors will seize the initiative, and their platforms will lose market standing.

The spectacle of vendors falling over themselves to lead the way in expanding platform interoperability is one of the many unexpected joys of following the SOA space.
posted by Phil Wainewright 8:03 AM (GMT) | comments | link