From time to time, we receive an RFP requiring support for XPDL. Even though we usually do not answer RFPs (Cf. Don’t RFP, Just DIY), I would like to comment on the need for XPDL, and why we think it’s essentially useless. It has been discussed here and there, but customers seem to remain confused about what XPDL is good for, how it relates to BPMN and BPEL, and how anyone could get any value out of it.

To be fair, XPDL is certainly the best specification that ever came out of the WfMC. Unfortunately, it does either too much or too little to be really useful. As Jon Pyke (WfMC’s former Chairman) said, XPDL’s primary goal is to: “store and exchange the process diagrams, or specifically to allow one tool to model a process diagram, and another to read the diagram and edit, another to ‘run’ the process model on an XPDL-compliant BPM engine, and so on.” Unfortunately, and further quoting Jon Pyke, “XPDL is described not as an executable programming language like BPEL, but specifically a process design format that literally represents the ‘drawing’ of the process definition.” As such, it cannot be used to store and exchange fully executable processes, but rather skeletons of processes to which muscles must be added for them to run. And because XPDL adopts a specific pseudo-execution model, it’s not appropriate for being used as interchange format for BPMN diagrams either. As a result, it’s unclear what it’s useful for.

Legacy workflow vendors (50 of which claim support for XPDL) will say that XPDL can be used to exchange processes from one tool to another, thereby achieving some level of process portability—hence the appeal for customers looking for ways to reduce vendor locking when drafting their RFPs. While seducing at first, this concept does not resist the test of real-world usage. To prove my point, let me tell you about a technical due diligence we recently conducted with a workflow vendor that tried to sell themselves to Intalio—we’re on an aggressive M&A path, acquired a second company last week, and will make many more acquisitions in the coming 12 to 18 months.

Without disclosing anything confidential, the technical due diligence unveiled something that is true for any workflow product I have come across during my 9 years working in the BPM industry: while most products support XPDL in some fashion (either for import, export, or both), the XPDL code they produce describes only a tiny fraction of the semantics required for the process to actually run. The rest is usually proprietary, implemented through custom code and custom libraries, and cannot be exported using any standard format. In many cases, it cannot be exported at all.

Furthering our due diligence, we scoped two projects out:

1. Developing a generic XPDL import tool for Intalio.
2. Developing a translator that would enrich the XPDL code to port workflows to Intalio.

Project #1 would give us the skeleton, while project #2 would add the muscle to the skeleton (the custom code to the ‘standard’ XPDL code), and would convert processes from this proprietary workflow tool to the Intalio platform. Based on preliminary scoping work, Project #1 would require 1 to 2 man months to complete. That was the good news. Then came the bad news: Project #2 would require 15 to 20 man years to complete. Then came the worse news of all: virtually nothing of Project #2 could be re-used should we decide to buy another XPDL-compliant workflow product in the future. In other words, nothing could be leveraged out of this work. Adding insult to injury, the cost of completing Project #2 would be greater than one year worth of revenue from the company we would acquire. In essence, the deal made no sense, and we decided to pass.

Unfortunately, this experience is symptomatic of the Workflow/BPM 1.0 industry at large. Because of fragmentation and lack of standardization (Cf. Why Standards Matter), customers cannot avoid vendor locking, and vendors looking for an exit cannot find any (many BPM vendors have been shopping themselves for years now). The IPO route is essentially shut down now (Metastorm cancelled its planned IPO a couple of weeks ago), and all Private Equity firms I talked to are drawing the same conclusion: any roll-up strategy in the BPM space is doomed to fail because it cannot be accretive. In other words, because all workflow products essentially do the same but do it in proprietary ways, they cannot be consolidated into a single product. As a result, 1 + 1 = 1.5 or less, and that’s not the kind of financial return investors look for, even during the most severe economic downturn.

So, what does it mean for customers? First, do not get fooled by XPDL’s promise. If you’re trying to reduce vendor locking by selecting a standards-based product, make sure to pick one based on standards that support true process portability, and the only ones that do that are the combination of BPMN and BPEL. BPEL processes can be ported from SeeBeyond (now Sun Microsystems) to Oracle, and from Oracle to Intalio, without losing anything along the way. No other BPM standard can do that today.

Now, if customers really want to check this XPDL box, we’ll be more than happy to build an XPDL import/export tool through our Demand Driven Development process. But remember: such an import/export tool is nothing more than an RFP checkbox. If you’re willing to spend money on it, so be it, and we will happily spend it for you. Just don’t complain if you eventually find out that it was utterly useless and wasteful.