I have to say it was interesting to me to read your point of view on the filenet product in particular. I’ve been part of several projects that replaced or augmented filenet “processes” that didn’t go too well. I can’t say for sure that it was because the filenet product wasn’t a well-rounded BPM tool, or too document-focused, or because of the specific people and implementation decisions and technologies involved… There are always many variables that contribute to the perception that the product isn’t meeting the need.

Fair or not, the perception of these customers was that filenet’s bpm capabilities were vastly oversold w.r.t. to “true” bpm offerings (their choice of words). They also felt fairly burned by the takeover by ibm and loss of direction there. Certainly the perception of the pure-play bpm vendors was that these document-focused bpm products didn’t measure up when handling non-document-centric processes (and that wasn’t just marketing, it was a firmly held belief, reinforced by enough market data to make it feel like Fact )

The oracle-bea acquisition is interesting too, but I think it is almost a non-event for BPM space. Surely BPM hardly even registered in Oracle’s collective consciousness as they did this deal to acquire the maintenance revenue stream of BEA customers. This was almost a pure-play financial play, the way I read it. I would assign a high weighting to the possible outcome that the ALBPM (what an acronym!) stuff just gets mothballed. If not intentionally, then when the BPM developers move on (the quick moves by oracle, while healthy in most respects, can result in losing key organizational members that have the critical knowledge in their heads to maintain a viable software product). There’s a chance they get BPM right, but I think there was already significant risk under the BEA umbrella that fuego would become a pure IT play, and lose its business focus. I think that risk is magnified by the oracle purchase as they are now two levels removed from charting their own destiny.

I don’t see any reason (yet) to see why IBM and Oracle would start thinking about the BPM space as other than a middleware problem. as other than an “SOA” problem. I’m waiting to be proven wrong, and I’ll keep reading your blog and others and keep my ear to the ground in the market, but right now I don’t hear the footsteps of the big players coming… it looks to me like the pureplays that are left still have a window of opportunity open where the bpm market isn’t quite big enough to get the big guys to take it seriously. And the strongest pureplays will benefit the most – which to me sounds like Lombardi now.

I realize, re-reading my post, that I might come across anti-oracle or anti-ibm – quite the contrary (a lot of my work has used software written by both companies!) – if I had businesses as large as their software businesses, I might not give BPM overmuch attention either And their strategic moves make plenty of sense whether BPM is a market or not – because they are justified by the economics of the middleware integration, cost savings, and maintenance revenue.

what’s tripping me off is when people talk about how BPEL and human tasks relate (also how BPMN and BPEL relate).

You say “In much the same way that other BPEL vendors handle human-facing tasks as second-class citizen, calling a subsystem using WSDL to manage them”

Have you ever considered one second, just one second that this could be the right thing to do? That the way you look at the problem, though perfectly understandable and to a certain degree logical, could be not universal enough? I grant you that in a document-centric workflow view, what you are saying works, but have you considered the millions of other processes that the business needs where it does not work?

If you take the view of an Object Lifecycle and you understand the relationship between a business process and object lifecycles, then, you can understand where and how BPEL fits, and where and how Human Tasks need to be handled (in a separate Task container).

For almost ten years, since XLang and the BPML days, everyone has banged their head on the wall trying to “orchestrate” processes (model & execute). You would think after 10 years, somebody really smart in academia or a research lab would have come out with a solution to the problem. Look at how hard it is for Marlon Dumas to build a BPMN to BPEL compiler? And Marlon is really smart. When that kind of things happen, it is probably worth to reconsidering the problem and see if it cannot be formulated in a different way, where the solution is more obvious.

Could you please consider this argument:

Object lifecycles are intrinsic to the (business) objects.

How can someone design a process that complies precisely and exactly with the lifecycles of objects that participate in that business process?

In reality, Object lifecycles are totally independent of the workflow (i.e. the tasks performed to advance their state). They are enterprise class business logic that you never want to violate and always comply with (imagine if I could transition a check directly to deposited to credited without ever verifying that the money was compensated somewhere?)

I could go as far as saying that a process cannot be modeled, all you can model is the instance of a workflow corresponding to particular a state change path. Haven’t you noticed how often the users give you the feedback that the “system” does not let them perform a task at a particular point (in a particular state), that should make sense? The very reason is because a business process model cannot accurately reflect all the lifecycles of the objects it manipulates.

If you were to construct your system from the point of view of the lifecycle and “graft” human tasks to the transitions (they enable the transition from one state to another), you would realize that the system is a lot easier to define and there is no need for any process definition whatsoever. The workflow of human tasks is then “observed” rather than centrally orchestrated or even modeled. It is the lifecycle of the objects which is orchestrated and results in a workflow.

I encourage you to draft the lifecycle of a PO, Invoice and Payment from the supplier perspective for instance and see it for your self. You will see how these lifecycles interact nicely with each other and how easy it is to graft/associate human tasks to particular transitions.