A lot of you know I am a big proponent of XPDL, the XML Process Definition Language. Not only because of the tremendous amount of good work that went into it, but also I see it being successfully used on a daily basis. It solves a real problem, and is available today. I am, apparently not the only one who feels this way.
In the last few weeks we have been investigating software that supports XPDL to try and get a definitive list, so we combined lists from several sources. The result surprised even me: we were able to identify over 60 different products that claim support for XPDL available today. Check the list at the WfMC site as well as my own list. Scan down the list of names, there are many important companies on the list:
- Large corporations: Adobe, Advantys, Appian, BEA(Fuego), EMC, Fujitsu, IDS Scheer, Infor, Interwoven, Global 360, IBM(FileNet), Oracle, Software AG, TIBCO, Unisys, Vignette to name a few of the bigger ones. It is also worth noticing that implementation is not limited to large corporations.
- Open source process editors such as Enhydra JaWE open source process editor and IT Pearls open source plug in for Visio which read and write XPDL.
- Open source process engines that execute XPDL directly, including Enhydra Shark, WfMOpen, Open Business Engine, Bonita, Workflow::WfMC, jawFlow, Pentaho, and others.
- Commercial process design tools like Cubetto Toolset, Jenz & Partner, Eclair Group Lynx.
- Specialized process tools, for example consider SimProcess which is a stand alone process simulation product. Or Zynium’s Byzio product, which can convert any unprepared Visio dirgram into an XPDL file for transferral to other tools.
- Adoption seems to be spread all over the world, including Rodan, HOGA.PL, R-DATA & Polsoft in Poland, Metoda S.p.A in Italy, Together in Austria, numerous companies in France, Germany, England, US, NEC Data & Fujitsu in Japan, Monosys in China, and many other parts of the world.
- Across the technological landscape, many of these are written in Java but there is also strong representation in the .Net world with Ascentn and Aspose both offering .Net products that support XPDL, as well as Perl, C++, and other language offerings.
There is another way to get an idea for the breadth of adoption. Consider Gartner’s Magic Quadrant for BPMS vendors for 2006. In the top three quadrants, there are 11 vendors listed. (Actually 12, but IBM and FileNet merged late last year after the MQ was released.) Here is the alphabetical linup of the top 11 vendors and whether they support XPDL:
- Adobe: YES
- Appian: YES
- BEA (Fuego): YES
- Fujitsu: YES
- Global 360: YES
- IBM (FileNet): YES
- Lombardi: ?
- Metastorm: ?
- Pegasystems: YES
- Savvion: ?
- TIBCO: YES
8 of the 11 top BPMS vendors clearly support the standard, and the other three might, I simply don’t know at this time. Is it fair at this point to consider the standard a success?
Here is the really strange thing, nobody seems to know this! Just two weeks ago yet another article was written in Computer Business Review where Tony Baer makes the following claims:
“Until now, workflow has been fairly virgin territory, given the failure of XPDL, an XML standard developed by the Workflow Management Coalition to attain critical mass support much beyond the classic document workflow crowd.”
“…XPDL got too specific, and began traipsing on the agenda of vendors like IBM, Oracle, and SAP. They dismissed XPDL as being dated due to its document workflow orientation.”
What strange comments! A quick review of the list of supporters make it clear that classifying this list as “classic document workflow” is very much off the mark. How unusual that IBM and Oracle are listed as non-supporters, when in fact they do have products supporting XPDL. Where does this conclusion about being ‘document oriented’ come from? Mr Baer is not alone in being confused by all the mis-information produced by corporate marketing literature, but I would expect a journalist to research more thoroughly than the product brochures.
The biggest misperception in the marketplace is that BPEL and XPDL are in some kind of a war. I have already covered elsewhere how this is silly, so I won’t duplicate it here. I think Jon Pyke’s response makes it clear how these very different standards serve very different purposes.
Yet, in conclusion, I would like to express my gratitude to Mr Baer. It was his article, after all, that prompted us to get off our duffs and update the list of products that support XPDL. As I said before, more than 60 products supporting XPDL surprised even us. I believe we have reached the tipping point.
Thinking Matters 
Hi,
I’m working for one of the big vendors you mentioned above. I just want to give you a reality check. Of course our products support XPDL modelling and export, but we don’t focus on that one. For us BPEL is the main technology, everything else is just available as basic implementation so that we can tick XPDL on the marketing slides.
Our experience also shows that XPDL is less portable compared to BPEL. There are so many competing extensions that it is not fair to call it a standard anymore.
I’m sure that every vendor on your list has its own opinions, and that those opinions probably vary depending on which of the products you look at.
Taking this away from the realm of being vendor or product specific, there are some fundamental differences between the capabilities and objectives of the standards. In my opinion, and very simply put, both standards live up to their names: XPDL – Process definition language; BPEL – process execution language. XPDL defines what the process looks like, to achieve required outcomes. BPEL tries to ensure you have a way to execute processes that can be modeled with it.
To my mind, XPDL has to encapsulate large set of requirements, with the need to model human interactive processes (which every organization in the world still depends on) alongside the interaction of external processes and systems. It provides the flexibility to allow business analysts define the complexities of the way a business runs, especially when you add people into the equation. From this, vendor specific extensions enable processes to be executed in the most effective way possible, given the methodologies and capabilities represented by the chosen software. Some input from the business analyst may be required to benefit from the distinctive features of a specific BPM product, but that is OK, since a customer can choose software that most closely maps to their business requirements.
The pure software and services focus of BPEL is a great model for defining pure execution requirements, where the interactions of process and web services are well modeled and understood, and there is little scope for execution software to differentiate, except at a pure technical level. There is little need in this model to enable different methodologies to be represented, so BPEL can become more portable across engines. Its value to my mind is how structured and portable it is. Its objectives set it squarely in the services process orchestration space, where it seems to be well accepted.
As the products in the BPEL space attempt to acknowledge the existence of people in processes, there is a risk that BPEL will grow (BPEL4People for example) and struggle to gain acceptance. Or vendor specific extensions will creep in. Modeling the complexities of human interaction, organizations, and collaboration in a process language that tries to enforce an absolute execution model will probably lead to a ‘lowest common denominator’ standard that is unacceptable to many would-be adopters.
XPDL and BPEL have separate objectives and they will overlap at times. At these times it may be better for the organization implementing human and systems BPM to look at ways of pragmatically handling end-to-end processes. Managing the ‘federation’ of processes, rather than trying to shoehorn everything into a ‘standard’ optimized for different objectives, seems to be the best way to go. End-to-end processes exist all across an organization, and at this point most organizations seem to struggle with gaining even the slightest visibility into what is going on, let alone attempt to model and execute that process within a process modeling or execution language.
I’m sure there are many opinions around this. I hope to see some lively discussion!
Cheers
Phil
Pingback: links for 2007-03-20 « steinarcarlsen
Pingback: Are Apples more useful than Oranges? « Go Flow
Hi Phil,
a business process should be designed in a way completely independent of any technology used to automate it. So neither BPEL nor XPDL are a good choice, because that are already technologies. One option might be BPMN, because you can still map it to various technologies. There are also some other more abstract process definition languages, but those are not official standards as far as I know.
Now, a company not starting from scratch probably has already many different execution environments. I have seen many customers who have SAP and Oracle and IBM in their infrastructure. So there is a big point in having a standard without extensions (also no BPEL4People), so that you can deploy the same processes to another vendor platform. This is important, because the customers are trying to consolidate their infrastructure. However, the business processes remain the same and just because of consolidation there should be no need to adapt the processes.
But anyway, I heavily agree with what you are saying. It really depends on what you want to achieve with the technologies. If you are free to choose it makes sense to select a platform with specific features you need.
Regards!
Pingback: BPMS Watch » The Real Issues with XPDL, BPEL, and BPMN
Pingback: Improving New Account Opening
Hi Keith,
I saw the list of Vendors supporting XPDL. That is noble, however all of them offer some Workflow Standards support and none was listed which provided BPMN support. What I would love is some Open Source Solution which provides a BPMN Editor/Designer and which serializes/saves/exports the BPDs in XPDL format (preferably XPDL 2.0 format). Now that would indeed be great.
By the way, your blogs are really informative and a pleasure to read.
Almost all of the main tools that support XPDL also support BPMN. That is a broad general statement which I believe is true, but let me be specific:
1. Fujitsu Interstage BPM support XPDL and BPMN
2. TIBCO Staffware supports BPMN and XPDL
3. IDS Scheer allows BPMN diagrams to be exported in XPDL.
4. Global 360 supports BPMN and XPDL
5. ITP Commerce is a Visio based BPMN modeler which exports XPDL
That is what I remember off the top of my head. There are lots of these now, and I expect to see quite a few more in the coming months. I would like to explore why you think that none of them support BPMN…..
To pick-up on Raj’s point, I’m not sure that there currently exists an open source BPMN designer that will export to XPDL.
Perhaps the project to watch is:
http://wiki.eclipse.org/JWT_Proposal
They certainly have this functionality on their road map. I’m not sure if it is implemented just yet.
There are at least 2 free products (not OSS) that provide this functionality:
http://www.activemodeler.com/AvantageFoundation has a free ‘Home’ edition that can export BPMN 1.o to XPDL 2.0.
http://www.bizagi.com may provide the export, I’m not sure, but this product is based on .Net.
There may be others. My focus would be on the Eclipse project.
I have received confirmation that the BizAgi product is able to exchange XPDL with other tools, as verified by Japan BPM association.
I’ve blogged more fully on Raj’s question:
http://jasonwoodruff.wordpress.com/2008/05/29/bpmn-2-xpdl/
Might be helpful, or not!
Pingback: BPMN 2 XPDL « Jason’s Weblog
Pingback: XPDL Fully Tipped « Thoughts on Collaborative Planning
After I originally commented I seem to have clicked the -Notify me
when new comments aare added- checkbox and now whenever a comment is
added I get 4 emails with the exact same comment.
Is there a way you are able to remove me from
that service? Appreciate it!
Have you evr considered writing an e-book or guest authoring on other websites?
I have a blog centered on the same ideas you discuss and would really like to have
you share some stories/information. I know my readers woul appreciate your work.
If you’re even remotely interested, feel free to shoot me an e mail.
Thanks for some other informative site. Where
else may I get that type of info written in such an ideal means?
I’ve a mission that I’m simply now running on, and I’ve been on the look out for such info.