A BPM Vendor Selection Criteria You're Probably Overlooking

While platform (.NET vs. J2EE) and architecture (SOA or not) steal headlines as the primary way analysts break out the BPM software market, there is a 3rd equally important way that separates vendors from the standpoint of how they approach process execution at runtime.

Does the vendor take an interpretive XML approach or a "code generating" approach?

It is important to clarify that the term "code generating" still applies to many vendors who claim to be "zero code" technologies. This is because while the business analyst is being shielded from writing code, what is actually occurring is the software is writing the code for them.....behind the scenes. Whether the code generation is rendered by the software or performed by a developer inside of a tool like Visual Studio, it still dictates what that BPM technology can and cannot do from a capabilities standpoint.

An interpretive XML approach brings with it capabilities that cannot be replicated by "code generating" technologies. They include:

• The ability to make in-flight changes to a process or processes without having to re-start the process from the beginning or without having to re-boot or re-start the server
• The ability to pause or re-start a process at any point
• The ability to deploy new versions of a process without affecting existing running instances
• The ability to specify the date and time a new version of a process should take effect without being dependent on staff to deploy the process at a specific date and time

Each of these 4 capabilities speak to agility and the most common example that people run into where this matters is realizing that an important step was left out of a process that already has dozens of instances in flight. With a "code generating" technology, you would be forced to stop new processes from initiating and wait for each process in flight to complete before making a change. Armed with a BPM technology that interprets XML, you can simply stop the process, make the change and re-start each and every instance of the process in flight. Further, those instances that have passed by where the change has been made can "back up" to the stop just before the change and be restarted from there.

A vendor's approach to executing processes at runtime is deep rooted in their technological DNA, much like their decision to build on a .NET or J2EE framework. While Web Services & SOA advancements continue to make framework less of an issue, a vendor's decision to go the interpretive XML or the "code generating" route will have profound impacts on their future marketability.