VOSibilities

Sandy Kemsley commented on the XPDL 2.2 effort to support the interchange of BPMN 2.0 model. I agree with her that it is a good thing. It will be a while before the BPMN 2.0 interchange formats are completed and even longer (if ever) before enough vendors support import and export of the format for it to be the lingua-franca of process models.

XPDL 2.1 is already supported by many tools, including ActiveVOS, so extending XPDL to support the new constructs in BPMN 2.0 will provide the fastest path for most vendors to achieve some level of interoperability of their BPMN 2.0 models.

Nonetheless, I’ve found that most people who have asked Active Endpoints about model import/export formats have been people who have the wrong idea of how to work with a BPMS. These are people who are trying to hold on to their old waterfall methodology for building software, where there are separate tools for building process models during analysis from the development tools that are later used to create the software. In that world, there is a constant need to translate back and forth between the tools as changes may occur on either side.

And there’s the rub. The roundtrip translation always loses so much information that the effort to keep the separate representations in sync and accurate outweighs the value of using the automatic export / import functionality. Eventually, changes made on the analysis side get redone on the implementation side by hand, and vice versa.

The right way to work is to let the BPMS own the model. Yes, you may want to allow early requirements gathering to use simpler modeling tools, but those tend to be fairly informal flow charts anyway. Once you get involved in real modeling you should use the modeling capabilities of your BPMS. By “real modeling”, I mean that you are at the stage where the precise semantics of the notation used is important, since it is going to drive the actual semantics of the resulting software.

In the early phases, the process models are diagrams where the labels on the diagram are what really matter. For example, the arrows coming out of an activity might formally imply that both directions can be followed at once, but the labels on the arrows have labels that imply that one one of them will happen. This is OK during the early stages of modeling, since it is another human who is going to be reading the model and they can guess what was really meant (or they can ask, if they aren’t sure).

Once you are ready to do real modeling, it is time to get the BPMS involved. That way the process model you create will go the rest of the way through the lifecycle of the project without need for translation, much less round-trip translation. How you get from the informal stage to the formal stage of process modeling isn’t really all that important. Yes, you can use XPDL 2.1, but it doesn’t really even matter if you have to redraw it from scratch. Drawing it is very fast in a capable designer like ActiveVOS, and the person doing the modeling is already going to have to be carefully considering each jot and tiddle of the original diagram to determine how to correctly model what the user really wanted to begin with.

Keith Swenson has posted this interesting list of questions to ask a BPM vendor.  I liked his emphasis on standards, since it is so important that the hard work that goes into creating business processes not be trapped in proprietary technology.  However, I think he concentrated on the wrong standard — XPDL.  If you really care about safeguarding your investment in your processes, the standard that you should care the most about is BPEL4People.

Don’t get me wrong, XPDL has its place.  ActiveVOS can both import and export XPDL version 2.1 (the latest version).   But XPDL is not a technology that will allow you to take an business process that is executable on one vendor’s BPM engine and move it to another vendor’s engine.  It just won’t work.  If you are lucky, the resulting business process diagram will look recognizable because the “abstract model” (as XPDL calls it) will import successfully.  But don’t get your hopes up about saving all the work that you did on the executable details.

The problem is not that XPDL has no place to put those executable details — it does.  It just doesn’t put enough constraints on what should go there.  There are just too many different things you can do, so no two tools do the same things.   Also, the bar for being able to say that you support XPDL 2.1 is just too low.  If a tool exports something that conforms to the XML Schema (possibly with liberal use of extensions) and import doesn’t barf on any Schema-valid input, then the tool conforms.  But don’t look for guarantees that you will see, much less be able to execute, anything reasonable.

By contrast, users of ActiveVOS have had great success in using BPEL-based business processes that were created by either IBM, Oracle or TIBCO tooling.  They have also found that the BPEL generated by ActiveVOS can be used by the tools of those other vendors.  That is real investment protection.

I do like Keith’s idea of having a list of questions for BPM vendors to help in the evaluation process.  I think the best way to organize such an evaluation is around four key areas.

Are the key BPM standards supported?

• Does the product generate executable WS-BPEL 2.0 processes?
• Can you model processes using BPMN?
• Does the product use the BPEL4People for activities that are handled by people?
• Are worklists and tasks exposed through the WS-HumanTask standard?
• Does it support the important enterprise web-service standards, such as WS-Security and WS-ReliableMessaging?
• How about non-SOAP access to services, such as JMS, REST or plain Java?
• Does the product import and export XPDL?

Does the development environment make the process developer highly productive, especially for processes that are larger than mere toys?  For some important examples, how easy is it to:

• Incorporate existing web services into a process?
• Detect changes to web service definitions and update the process accordingly?
• Define services provided by the process (including defining XML Schemas and WSDL)?
• Define new human tasks using existing data definitions (XSDs)?
• Prepare the input data for human tasks or services?
• Support services that “call back” into a running process, and specify the appropriate data to use for correlation?
• Find all uses of a variable within a large process?

An executable process is deployed software.  What support is available for ensuring and maintaining its quality?

• Is there test case generation?
• Is there test suite support?
• Is there remote debugging?
• Is there Metadata for controlling the difference between staging and deployment?
• Can you new versions without effecting existing process instances?
• Can you deploy new versions that do change existing process instances?

What can be done to a running instance?  Can you:

• See where it has been (with anotations on the process diagram)?
• View current and historical data?
• Change data?
• Skip activities?
• Single step through activities?
• Rewind execution, optionally reverting all process data to what it was?

What kind of runtime console support is there?

• Can you get reports with either operational or business information?
• Can the end user create any kind of new report and incorporate it into the runtime console?
• How powerful is the query capability to find a process instance you care about?

All of these characteristics of a BPMS will eventually be important to anyone that is creating the kind of critical business processes that will really transform a business.  Knowing the answers to these questions can help you to avoid making the wrong choice.