The BPM Engine is Commoditized

Scott Francis
Next Post
Previous Post

adobe-spark-17I remember when the battles were fought over whether BPEL-driven engines would win over BPMN engines, debates largely settled by the time I started blogging.  In the early days of BPMN, how you implemented the language – or whether you did at all! – in an engine was a real point of differentiation in the market.  This is how Lombardi Software, for example, made it’s mark on the market before being acquired by IBM.  Fast forward more than a decade, and the engine itself just isn’t as differentiating. 

This shouldn’t be that surprising.  Several years ago a friend of mine, Johnathan Berkowitz, wrote that “The Era of Technical Differentiation is Over” – and in large part, he was right.  Not that there aren’t technical differences that matter – there are.  But those differences aren’t the highest order impact on your successful use of the software.  And they aren’t the differences that change a customer’s buying behavior.

But if the engines are commoditized, why is there a proliferation of BPM engines – isn’t that an argument against engines becoming commodity?  For one, the barrier to create a new engine in the open source world is quite low.  For another, the proliferation of BPM engines is just further proof that the engines themselves are a commodity.  There’s Activiti, jBPM, Camunda, Signavio (Effektif), Flowable, Bonitasoft.  And commercial only solutions like IBM, Pega, Appian, BP Logix.  What’s that?  You prefer a NodeJS -based BPM Engine?  We have you covered.  And it won’t be the last new engine on the market.  I’ve talked to companies who rolled their own for internal use – though I question the incremental value over just adopting one of the many market alternatives that are already complete.

What is apparent to us at BP3 is that nature abhors a vacuum. If there’s a market opportunity someone will pursue it – and if there’s an opening for a different type of BPM engine or implementation, someone will build it.  They’re not differentiating on technology, per se.  The differentiation is on experience – often on the developer experience rather than the end user experience.

I can hear the engineers who write BPM engines telling me otherwise.  They’re doing advanced stuff with OSGI, and Java stacks, and scale-ability. And they are.  And it is interesting and good. But are customers buying based on those features?  Is it the “highest order bit”, to use computer science terminology? Or is Berkowitz right that the era of technical differentiation is over [in BPM engines]?  Am I right that these arguments basically boil down to differences in experiences and preferences?

So you pick a tool like IBM BPM because you appreciate the way all of the BPM functionality is represented in the process designer – a unified development environment for building business processes.  You might pick IBM because of the sales experience as well, or because of the brand.  You pick an open source engine because you really just want to embed it as a java library and leverage it with coding tools.  Or you pick the NodeJS engine because you’re a full-stack Javascript developer. You’re really selecting based on the development experience that most appeals to you. 

There is room for BPM entrants in the world. But at the same time, a new BPM engine will need to prove its worth over time to justify continued investment.  We have a lot of respect for all of the players involved – the BPM community is close one.  The thought leaders and leading developers know each other and meet at conferences. There’s a lot of mutual respect. And competition. 

Does BPM Engine Commoditization mean that it’s easy to build a successful BPM program or that you can be successful working with anyone?  Does BPM Engine Commoditization the end of innovation in BPM… or the beginning?  Stay tuned.  More to come on this channel.


Related Posts

Commodotizing the Complements
Apple Experience
Customer Experience and BPM