Ismael’s Advice to Competitors: Use our BPEL Engine!

Scott Francis
Next Post
Previous Post

Thanks to Sandy’s blog post, I’ve once again been pointed to an interesting post in a blog I didn’t have in my Google reader (I’ve now added it!  thanks again Sandy!), in which Ismael Ghalimi gives unsolicited advice to the BPMS competition out there.  I can sum it up as:  “Use our BPEL engine!” I want to discuss this theme in three parts:  The Case for Change, The Proposed Solution, The Proposed Benefits. The Case For Change. The economy is hurting, and logically software vendors selling perpetual licenses will be commensurately hurt by reduced purchasing plans.  It isn’t a bad premise, though I will point out a couple of things.  During a slowdown in the early 90’s, software that had good ROI sold at accelerated rates, while software without large ROI stagnated or didn’t sell at all.  Products that extracted cost from expensive operations enjoyed great success.  On the other hand, during the 2001-2003 slowdown, I saw something else happen.  Instead of buying software to make complex processes and operations more efficient, I saw companies dramatically simplify their processes or products to eliminate the need for software (for example, PC and Server configurations became dramatically simpler, and fewer configurations were offered.  The same thing happened in telecommunications.  Complicated sales processes got streamlined).  I can’t say whether the current economic environment will spur more software sales in BPM or less… I have visibility to the deployment side, and companies that already own BPM are looking to get more ROI out of that software $.  But for those without BPM software, I’m not sure that they can effect the same kinds of rapid ROI that BPM platforms provide, and therefore I’m not sure how many of them will back off of plans to acquire BPMS packages.  Ismael asserts that many of their purchase plans will change.  I’m not so sure. If I look to 2003 and 2004 as examples, IT departments dramatically cut spending in the 4th quarter to preserve earnings for the current year (and yet, it didn’t stop BPMS vendors from selling in those quarters).  In the new year, however, priorities were reassessed and projects that were deemed to have a large probability of a large ROI were started. I can’t say for sure how this year will play out yet for BPMS vendors. So, I’m not sure I buy the economic argument. But I do buy that replacing proprietary solutions with open source solutions or de facto standard solutions makes sense. Why? well, you focus your engineering efforts on the parts that differentiate you, and you rely on the Open Source community to provide for the plumbing elements.  If you find a bug, you fix it, build it, submit it back to the community, and benefit from gradually increasing quality of the overall solution.  Ismael uses the Database example, but I’d say this analogy isn’t perfect for his purposes, because the “winners” in the database space have been primarily licensed software vendors. A better example for BPMS solutions would be the J2EE stack.  Once upon a time it would have been hard to avoid using Weblogic or Websphere, but JBOSS has become a viable solution, and it doesn’t have additional licensing costs (though, the support contracts are actually quite expensive at present).  And you certainly wouldn’t want to write your own J2EE or LAMP stack for your BPM product – you want to focus on BPM and let someone else solve those interesting platform problems for you. The Proposed Solution. Ismael proposes embedding (OEMing) Intalio‘s BPEL engine in competitor products. In terms of his Blog post, it looks like “BPEL Engine” and process engine are being equated.  However, I think that several of the vendors use something closer tied to the parallel processing notation BPMN, rather than to the XML notation BPEL (there is a brief reference in his post that BPEL’s pi-calculus is better than Petri-nets, but without any supporting data directly in the blog post, since I think that was a bit of a tangent… and certainly doesn’t fit in this post!).  So while they may use a conversion of BPMN to BPEL and then in turn use a BPEL engine, it isn’t necessarily the case (they may, in fact, have a BPMN engine using some other technology).  This introduces some friction for vendors to adopt Intalio’s BPEL engine as a literal replacement for their own processing engines.  Nevertheless, I’m sure some vendors would benefit from getting a BPEL engine embedded even if it isn’t their main processing engine… (and therefore, worth it for Intalio to pursue such agreements where possible) Looking at his database analogy… This isn’t the same as deciding not to build your own DB and “outsourcing” this technology to Oracle, Sybase, or MySQL… Its actually the equivalent of Oracle deciding to replace their Database Engine with MySQL or PostgreSQL on the grounds that they are cheaper and scalable and times are tough so Oracle could save some money by doing so… but read on for why that may not be their decision… The Proposed Benefits. No more investment in “stack” technology, pick up a scalable BPEL engine.  The key here is, does the BPEL engine Intalio produces eliminate any competitive advantage or perceived advantage, that the other BPMS vendors have vis-a-vis the competition due to their own respective process engines?  I can’t answer that question for the BPMS vendors, but if we go back to the Oracle analogy, I think Oracle has done quite well (so far) by sticking to their guns and their own DB engine.  There are switching costs that can’t be underestimated too badly – its costly to switch someone from one Database to another… not to mention the monumental task Oracle would have of switching their own software stack to run on an open source database.  Similar friction would exist for the BPMS vendors to switch their process engines out for a BPEL engine. Conclusion. So, it isn’t that I think this is a bad idea, I just think the bar may be really high, and I’m not (yet) in a position to judge if Intalio passes the bar (or if the other vendor solutions don’t set the bar high enough).  Ismael and Intalio should keep pushing this angle though, with the BPM vendors.  I don’t think any of them will be picking up the phone to call Intalio, as Ismael suggests, but I would suggest he approach them about co-development and OEM agreements.  Having the industry solidify around a common process engine would be a good thing, assuming that process engine is truly superior to all the engines out there today, and might help accelerate adoption of certain standards and innovations.  It would make it easier to expose useful APIs to the developer world (Ismael has some posts about building for developers that are pretty good too), it would make it easier to write solutions that will work across more than one BPMS vendor.  And it would make it easier to push BPMS education down into the college levels at some point.  Still, it looks like a tough hill to climb from here.  Keep fighting the good fight, Ismael.