BPMN 2.0 Should Remain Focused on Notation

I am watching a number of comments being placed about a new effort for BPMN 2.0. Vishal Saxena says that the BPMN 2.0 metamodel should maintain this flexibility that BPMN 1.0/1.1 has. No argument there. Sebastian Stein says that BPMN is missing an exchange format, and clearly he does not know about XPDL. He goes on to say that the real problem is a lack of clear execution semantics. He points out that the OMG discusses two approaches: BPMN defines the semantics, and BPDM defines the semantics. Bruce Silver comments that the first approach would be the most value to the BPM community. We seem to agree that BPMN needs more clarity in expression. I suggest that there is a third approach that the OMG should consider. Continue reading

London Calling

It has been a while since I given an update on the work of the WfMC Technical Committee. The last couple of months has been busy, and this is all building toward two standards tutorial events: one in DC and one in London. Before we get to that, it has been a busy couple of months:

XPDL 2.1 – A new update to this specification due to the hard work of a number of people contributing and painstakingly edited and assembled by Robert Shapiro. The WfMC working group 1 met in Nashville and voted for adoption of the 2.1 spec as it is. The new version contains extensions to support BPMN 1.1 (also just released) and include a new section on conformance testing. This is an important step because it allows us to specify several levels of conformance, and a way to measure which level you are at. Bruce Silver contributed significantly to this approach. Tom Laverty from Global 360 developed an XSLT script for performing the test. All in all, it is another step forward in the WfMC effort to allow for a process design ecosystem.

BPAF – A new acronym is born. The Workflow Reference Model describes interface 5 which is a way for events and other historical information to be passed to an analytical tool for processing and mining. At the Nashville meeting a decision was made to call this “Business Process Analytics Format”. This is a standard XML structure which a BPMS can generate, and Process Intelligence product can consume in order to product high quality analytics. Of course many such tools can be programmers to take a stream of event in any format, but a standardized format will allow us to fine tune the precise semantic meaning of each attribute of the event, and make it far easier to hook various types of process engines together without programming. There is a working group led by Michael zur Muehlen and Shane Gabie.

Wf-XML – Main focus on creating a new RESTful version of this specification in cooperation with Open Geospatial Consortium. Find out more about this at GeoBlicki.

Events – there have been a number of successful BPM tutorial events:

  • Las Vegas, Feb 2008, BPM In Practice at Gartner BPM Summit drew a full room of 60+ people for this three hour tutorial by Keith Swenson and Robert Shapiro
  • Nashville, Feb 2008, BPM In Practice at the BPM Tech Show was a repeat success with the three hour tutorial. This one was recorded and is being turned into a book!

Future Events – please mark your calendars, the following:

The Right Amount of BPMN

After a few months without much BPM discussion, then I blinked and found that I have been missing the Great BPMN Debate. To bring you up to speed: Michael zur Muehlen and Jan Recker have been studying how people actually use BPMN to draw business processes, and have counted the occurrance of rate of various elements. He summarized this in a blog post,which came to the conclusion that practitioners could focus on learning and using a small subset of a dozen BPMN elements, that vendors could prioritize implementations to get the more common elements first, and that some elements were used so rarely that the value of their existence was questioned. Continue reading

The Diagram IS the Meaning

Bruce Silver put together a summary of The Real Issues with XPDL, BPEL, and BPMN where he explained better than I could that the aspect of portability that is more valuable depends on what you’re trying to do. He correctly points out that “XPDL captures the diagram, while BPEL captures the process semantics.”

Bruce brings BPMN into the discussion as potentially the standard that is possibly the most important. There have been a number of discussions recently of the relation of these three standards, Continue reading

The Tipping Point for XPDL

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: ?

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.

Feb 5 will be another Bay Area Workflow Seminar

I heard a funny rumor today: someone heard that the OMG was buying the WfMC in order to put an end to XPDL. I am sure the OMG folks find this just as amusing as the WfMC members do. And I can assure you that no such thing is happening, probably more due to OMG unwillingness to shell out the money than WfMC unwillingness to accept the cash. Continue reading

BPM Standards Tutorials, Sept 29, Germany

Key members of the BPM standards community are coming together in Mainz Germany on September 29 to present six hour-long tutorials on subjects relevant to getting BPM system to work together. The tutorials range from general overview of the BPM market, to specific detailed presentations on standards. For those vendors who are already familiar with BPM there is an interactive XPDL design strategy session to discuss specific implementation approaches.

This is presented as part of Business Process Management 2006 which is a four day event, the BPM Standards will be presented on the last day, Friday. While the first three days are primarily in German, the BPM Standards day will be presented exclusively in English.

The schedule is:

  • 09:00 Welcome and Introduction
  • 09:10-10:00 BPMN/XPDL overview
  • 10:00-10:45 BPMN/XPDL details
  • 11:15-12:00 Human BPM (workflow) vs. EAI BPM (Service Orchestration)
  • 12:00-13:00 Lunch
  • 13:00-13:45 What is BPM? What is Workflow? The Business Value of BPM & Workflow.
  • 14:00-14:45 Relationship between BPM and SOA – How to leverage what you have.
  • 15:15-16:00 XPDL vs. BPEL
  • 16:00-16:30 Panel Session, Q&A, Roundup, Feedback

The presenters include Jon Pyke (WfMC Chair), Robert Shapiro (Global360), Keith Swenson (Fujitsu), Saša Bojanic (ProZone), Justin Brunt (TIBCO), Ken Mei (Global 360), Philippe Betschart (W4 Global), Philip Larson (Appian Corp), Thomas Olbrich (Chair Business Process Management 2006), and draws upon work created and helped along by the Workflow Management Coalition.

Here is a detailed schedule of the presentations. Hope to see you there!

Throw Out the Diagram?

I ran a “Round Table” at the BPM ThinkTank on the subject of BPMN and XPDL. There always is the question: “Why not use BPEL?” Then I explain how XPDL holds the graphical layout, the X & Y coordinates, the size the nodes, the paths of the lines. BPEL has not support for the graphical layout.

“But you don’t need to save the graphical layout!” Continue reading

The BPMN-XPDL-BPEL value chain

I got the chance to participate on a panel session at the BPM Think Tank in Arlington VA on May 24 2006 on the subject of BPM Standards.  Richard Mark Soley was on one end representing OMG and the BPMN standard. John Evdemon from Microsoft was on the other end representing BPEL for which he is the TC Co-Chairman. I was between them representing XPDL from WfMC. The order was random (although Richard suggested we were ordered by height) but as it turns out this is a natural order of progression for use of these standards.  Sandy Kemsley described this as the “BPMN-XPDL-BPEL value chain” in her post about that panel session. (Thanks Sandy for the term!)
Many people today automatically assume that BPEL and XPDL are direct competitors. This is not at all true. BPEL and XPDL are entirely different things for entirely different purposes. I will repeat that statement a few times here to emphasis it. But first, and quick summary of how they are different.

BPEL is an “execution language”. It is a programming language that has variables and operations. The operations can send and receive SOAP messages, and there is strong support for XML and XML transformation. It has constructs that make it easy to call multiple web services at the same time, and synchronize the results. It does not have any concepts to support the graphics of the diagram; activities do not have a position and size, and there is no representation at all of an “arrow”.

XPDL is a process design format. It is a file format that represents the “drawing” of the process definition. It has X & Y coordinates and node size. It has a concept of lines, and points along the line that give it a particular path. The nodes and lines have attributes which can specify executable information such as roles, activity descriptions, timers, web service calls, etc. XPDL 2.0 contains extensions in order to be able to represent all aspects of BPMN (BP Modeling Notation). The goal is to be able to save and exchange the process diagram.

The goal of BPEL is to provide a definition of web service orchestration, the underlying sequence of interactions, the flow of data from point to point. Ultimately BPEL is all about bits and bytes being moved from place to place and manipulated. It does not however attempt to represent the drawing that you used specify the orchestration.

The goal of XPDL is to store and exchange the process diagram. It allows one process design tool to write out the diagram, and another to read the diagram, and for the picture that you see to be as similar as possible. It does not, however, guarantee the precise execution semantics. As you see, BPEL and XPDL are entirely different things for entirely different purposes.

The different usage is best represented the diagram below. At the top are various design level tools. At the bottom are execution environments. XPDL can be used to carry the design from design tool to design tool. BPEL, XPDL, or other formats might be used be used to communicate the executable process to the engine. Generally, a vendor specific design tool is necessary to translate the design into an engine specific format. Generally, it is not possible to take executable code from one vendor’s design tool, and execute it in another vendor’s engine. Even with BPEL, which many believe was for this purpose, does not at this time allow different engines to run identical copies of BPEL code.

Diagram A

The XPDL file can provide this design interchange because it offers one for one representation of the original BPMN process diagram; it can be written, and re-read to recover the original diagram. BPEL, on the other hand is a non trivial mapping which is widely recognized as being one directional: you can take a BPMN diagram and produce BPEL, but it is difficult or impossible to recover the original BPMN diagram from the BPEL. This is not surprising since it was not designed for process design interchange.

Process interchange is ver important to customers who are investing a tremendous value in their process diagrams, and do not want to locked into a single vendor. (The vendors may desire this lock in, but never forget that the customers are paying the bill and have a choice.)

The importance of process design interchange will increase as the market matures. Currently, without design exchange, a single vendor must supply all of the tools that an organization might use. As the market matures, we can expect to find specialized tools that provide one function better than the vendor providing the engine. Or there will be people who are trained on a special tool and don’t want to lose that skill to pick up a new vendor version. The result is that we see a complete ecosystem of specialized tool that all work at the design level. This might be depected as below:

Diagram B

You might ask, if BPEL does not manage to communicate the execution representation to various engines with complete fidelity, why then would we expect XPDL to exchange the process diagram with complete fidelity? The answer is simply that is does not need to. One design tool does not understand the output from another tool completely, but every design tool will understand the most important parts (the form and shape of the diagram) as well as many standard BPM attributes. Because the model is communicated from design tool to design tool, if the transfer is not perfect, you have a chance in the receiving tool to fix it up. Not perfect, but both useful and pragmatic.

Not every tool needs to understand the complete diagram. A simulation tool for instance will use the standard parts of the diagram, but probably ignore things like the attributes that define web service calls, since simulation does not need to know this.

One of the most important aspects of XPDL is the extensibility mechanism. Each tool has specialized requirements on the diagram, it can represent these using extended attributes. Other tools will not understand these extensions, but they will carry the extensions along. Thus a tool specialized to clean up the layout, might manipulate the graphical aspects of the model, and return a cleaned up model including all the extensions back to the original source without losing any information. Enhydra JaWE for instance is an open source XPDL editing tool has been publicly demonstrated to read an XPDL file from Fujitsu’s Interstage BPM, edit, and return without loss of vendor specific extensions. JaWE even allows you to view and modify the extended attribute values.

Some execution engines take XPDL directly. Fujitsu’s Interstage BPM does because it is workflow style BPM and it is important for human activities to retain their identity even while executing, so that run time modification and process migration can be readily supported. That is the choice that a particular engine makes.  Some of the more EAI-style engines may use BPEL, but even in that case the portability is not proving viable, and some engines are going straight to the underlying technology such as Java, C#, Ruby, etc.

These are the differences in the roles of these three important standards. Our sitting order on the panel was appropriate and fitting because users will usually start by drawing a BPMN diagram, saving the partial diagrams as XPDL during development, and ultimately translating to BPEL for transmission to an EAI style BPM engine. These are three very different and very compatible roles.  But remember this: BPEL and XPDL are entirely different things for entirely different purposes.