One of the biggest challenges with the BPM market is working out which tools are capable of meeting the requirements of your business. Although the term standardisation is thrown around often there is very little that is common between BPM platforms. Selecting a BPM is a major undertaking.
In this blog I will talk about a detailed review I have performed that involved deep analysis of the top human centric commercial players along side a number of open source options to actually see which of this tools could meet the key requirements of a real world Enterprise Architecture. Something the salesman for the commercial products were all nervous about.
In this review I took these BPM technologies and ran through a detailed analysis, which includes not only feature analysis, but installing and prototyping on the product to assess its fit to a complex problem domain. The effort was worthwhile as numerous areas that were brushed over by the pre-sales guys actually proved to impact the design of the architecture significantly.
The analysis covered players such as IBM BPM (Lombardi), Appian, Intalio, as well as smaller but worthwhile players including ones like ProcessMaker and JoGet.
The final report went into fine level detail discussing how each key feature was implemented and how each products limitations or functionality will impact the design of a modern day architecture based on a BPM centric design. I was particularly focused on human centric capabilities as I personally believe that back end BPM is the thing of the past and the future will be easy to integration BPM that can integration with a human experience efficiently.
Today’s world of one BPM for each problem has to eventually go, business cannot afford to have three plus different BPM’s that all require different skills. The current sales pitch is one BPM for humans, one for backend processes and one for documents, this is the crazy world of effective marketing and not a necessary technical reality. I believe it will change, hence the winner is likely to be the human centric technologies.
Some of the key findings my analysis uncovered include the following:
- Although we sometimes pick on IBM for being heavy weight and costly (sorry IBM) in this case the IBM BPM product was impressive. It had a number of limitations and issues that need to be understood, however overall provided a good BPM technology. IBM tend to focus on less interesting aspects from a sales viewpoint such as back-end capability so it really paid to take a closer look. IBM pre-sales worry about customers on their old platform and focus on ensuring these customers see their old outdated products are still there, but the beauty of BPM is in the Lombardi components not the IBM ones (Lombardi was a recently acquired company). Lombardi has designed a very interesting technology with good and simple integration capabilities that allows for rapid development. IBM BPM also drags in another great technology called BRMS (ILOG JRules to be specific which is another acquired company) but that is a subject for another blog article as there are a number of important considerations here and still some work for IBM to do in future releases.
- The open source options did surprising well, particularly Intalio both the open source and enterprise versions and it provides an ability to allow for flexible designs and complex data mappings as well as BRMS options with the enterprise version. The learning curve was higher than expected however this was mainly due to its capability. The GUI capabilities are well worth understanding and offer customisation options that none of the commercial products can do.
- The big players such as Appian had a number of fundamental limitations that in my opinion “should” have been reported by groups such as Gartner and technically were in conflict with the “sales pitch” that was being told. If this had been explained upfront I still think they have a good product overall but using that product in the wrong situation would spell potential disaster in certain architectural designs. In particular its XML handling had a number of fundamental limitations which also impacted the GUI and how rich a data model could be, ultimately pushing more complex problems towards total customisation and ground up building of interfaces.
- ProcessMaker, initially did not seem particularly interesting due to its painful installation limitations and fact that it was built on a PHP was is not typical of BPM tools. Don’t get me wrong I appreciate PHP but its not typical of this type of technology stack because of the extra architectural effort needed to scale it properly. With that initial concern aside I was pleasantly surprised to discover the modelling concepts were actually very structured and developing medium scale processes was quite fast. It was let down by similar problems as was found in tools such as Appian. I’d keep an eye on this tool going forward.
Now, the final report took months to compile due to the real world prototyping and goes into detail as each product was installed and tested against a standard insurance domain problem. If you would be interested in reading this report, it is in the process of being updated with new details, so it can be made available for purchase if desired. Shot me an email on info @ paulparisi.com.au and I will let you know when its ready.
The key lessons learnt from the analysis were this:
- You cannot assume data modelling capabilities are uniform across the range, no standard notations are being used yet, no standard interfacing techniques are agreed and in fact feature sets are varied. Some tools even claim to have functions like document management and portal, however the definitions don’t conform to industry terms, i.e. document management means a document can be put on a process, not a document can be managed through a lifecycle by the BPM engine. Similarly with portal technology in some cases this meant meeting basic standards such as JSR168 and others it meant providing a web page that could be “hacked” into a different looking web page.
- Web service capabilities particularly against .NET generated web services were extremely poor, and with most options would require creation of a façade to wrap existing web services. A few stand out products did actually provide stronger capabilities here, however given these technologies are based on SOA it was a shock to see such limitations present in the products given their maturity in the market.
- Integration capabilities vary massively across the range, from clean simply solutions of uploading a “jar” file with basically any interface code was available to completely locked environments where integration really meant talking to the vendor or accessing only a web service defined to work with their standards.
- Talking to the vendor in some cases meant putting the whole project on hold as the turn around time was shocking. The fast growing vendors are the ones to be careful of because its impossible to grow a technical capability at the speed that a sales team can sometimes drive a companies growth. With no technical capabilities customers get left out with a broken tool and no one to help them work around bugs.
- The speed to assemble the sample insurance problem varied from 2 weeks on one product to 5 hours on another. I could not have anticipated this without doing the level of analysis that has been done here. In dollar terms do you want to be stuck with the product that took 2 weeks to do the same job as the one that took 5 hours? Calculate the cost of that at say a process consultants rate and I think you will see that “analysis” of the BPM’s is worth it.
In conclusion I hope this has given a small taste of the variety of considerations with selecting a BPM tool. I hope to make the full report available at some stage if there is interest. Feel free to contact me if your dealing with this problem and need some advise on info @ paulparisi.com.au.