BPM 2.0 Epiphany

Earlier today, I participated in a lively ebizQ panel organized by Sandy Kemsley, with Phil Larson, Director of Product Strategy for Appian Corporation, and Phil Gilbert, Executive Vice President and CTO for Lombardi Software. We discussed about BPM and Enterprise 2.0, and had lots of fun arguing whether it was important for a process modeling tool to be web-based or not. But what I will remember from this call is the epiphany I got about BPM 2.0, and what makes Intalio’s vision for BPM so different from the one of our competitors, Lombardi first among them.

If you read Phil Gilbert’s report on the panel, you quickly realize that his approach to BPM is not very far from the Business Process Reengineering (BPR) school of thought that was so popular in the early 90’s. It’s radically top-down, exclusively driven by abstract process models, and inescapably tied to a traditional software engineering process, whereby a lot of code has to be written to make the whole thing work.

When looking at Lombardi’s recently released Blueprint, I cannot help but think about SAP Solution Manager, a tool originally developed in partnership with IDS Scheer. With it, business consultants can design abstract processes, then let technical experts write a bunch of ABAP code to make the processes executable. While this may sound straightforward, it’s actually a receipe for long-term disaster, for it bakes the process into code, and makes it virtually impossible to change over time. Changing the picture is easy, changing the underlying code is not. SAP understands this problem very well, which is the reason why they have been trying to develop a BPM solution for so many years. Why they failed is another story, but they are still at it today.

Well, Lombardi’s BPM solution works very much the same way. Business folks use Blueprint to design non executable processes, from which a process skeleton is created. Then, Lombardi technical consultants extend the high-level process model by adding boxes and arrows that are necessary, but not sufficient, to make the process executable. Finally, even more technical Lombardi consultants write a bunch of JavaScript code—yes, you read well, JavaScript, of all languages—behind each box and arrow in order to make the process fully executable. How you could ever ensure roundtrip engineering through this three-step waterfall implementation process is beyond me, but savvy marketing will make you believe that they can.

When I look at such a model, all I see is a complex platform for the industrialization of top-down Business Process Reengineering efforts. I am sure that some customers will be seduced by the idea, but I also believe that most customers know better. They’ve been there before, and they know that the reason why BPR projects failed in most instances is not because we did not have the right technology back then. It’s because the approach was fundamentally flawed, mainly from a life cycle standpoint. If you rely on a waterfall implementation process to support the development of new processes, you will never get the agility that was promised to you in the marketing brochure. Ever.

This is precisely the reason why BPM 2.0 advocates a Zero Code, One Click Deploy model, whereby there is only one process model, and you do not need to write code to make it executable. This approach is neither top-down no bottom-up, it’s middle-out, and contrary to what Phil would like you to believe, it works for both small organizations as well as larger one. In fact, the largest BPM system ever deployed was built with it. It manages a process that has over 250,000 steps, 250,000,000 instances, runs over 5 years, and is used by 100,000 people daily, in order to manage 25,000,000 farm animals. Zero Code is not a gadget, it’s what makes BPM 2.0 work. Big time.

Having said all that, please don’t get me wrong Phil, I really like what you’re doing. Your tool is pretty sexy, and for simple processes that do not require integration with third-party systems, it seems to be working fairly well, much like Appian’s does by the way. But as you and I know, most processes require such integration points, and you won’t be able to support them with the proper lifecycle without using proven technologies such as BPEL. JavaScript is cool for AJAX widgets, but it won’t scale the way BPEL and Java can. We happen to have a fairly good BPEL implementation, and it’s available under an open-source license. So, if you ever decide to change your mind about BPEL, we would love to help you integrate our process engine into your product. You, us, and your customers would all benefit from it.