InfoQ's Will Business Adopt BPMN 2.0? made me write up my thoughts on a
blind spot in the BPM world.
Very big attention goes to the business side of BPM. And that is for good reason as that is the side that makes the money go round.
Bruce Silver's quest to learn everyone the fine grained details of BPMN is really valuable. That's what I consider the efforts needed from the business side to align business and IT. The levels of BPMN that Bruce initiated are really important and make it possible for BPMN to support a broad audience, from occasional reader to full time business analyst. I believe BPMN contains already depth enough as the finest details are probably only reserved for the happy few.
The technical side of BPM (and BPMN for that matter) does not get the same depth of attention. Historically, BPM's goal was to eliminate the need for IT people all together. Recently a general awareness has grown that IT and developers can't really be replaced by non tech business analysts using a magical BPM System.
But many people in BPM don't seem to get the full implications of that trend. This post is a protest against the tunnel vision that seems to be as stubborn as
a greenpeace activist in a rubber boat. In the industry, everyone talks about business-IT alignment. But only the business aspects are looked at in depth. The requirements that technical people have for BPM Systems are still overlooked and ignored.
The challenge for BPM system builders is: "How can we offer this tool to developers so that they can provide business people with the agility they need?" That's where there has been a painful silence.
One aspect that has been tackled properly in the BPMS community is web services. BPMN 2.0 is basically a superset of BPEL. That is good. In the infrastructure of an average organization, you'll find many off-the-shelf products and internal components that expose functionalities as web services. So there is definitely the technical need to call out to web services from a BPMN process. A good BPMS should make it easy to call out to web services and to deal with the data manipulations of XML structured data.
The mistake of associating BPM with webservices (cfr BPEL) in the past comes from a lack of technical depth in BPM. From a CIO perspective, it might make sense to standardize on web services for communication between different systems in an organization. But assuming such a unified web services world as a prerequisite is really shortsighted. Building a BPM System with a hard dependency on a WSDL infrastructure and places such BPM solutions automatically in a niche.
As a first example, RESTful web services have been given too little attention. Also those can be found in many of today's organizations and hence the process language should be able to work with them easily.
Even more so Java architectures are under emphasized. Calling a Spring bean from a BPMN process with a Java Unified Expression Language makes it so much easier for developers using Spring. The ability of the BPMS to use the dataSource bean and the transactionManager bean straight from the developers' Spring configuration is also needed to achieve agility. Another example is storing native Java objects as process variables. Or even easy linking between process and the user's domain objects that are persisted with JPA or hibernate. Also declarative transaction demarcation (aka asynchronous continuations) is a really valuable instrument to merge technical developer's concerns into a process for which the diagram is expressed on a business level.
As a side note, I'm very happy that BPMN 2.0 doesn't assume a unified WSDL world and makes it possible for BPM System vendors to build in native support for e.g. REST, Java, Grails or any other technical aspect.
Since as long as I can remember, the business-only focussed BPM market has always been very promising. And yet, that very market remains fragmented and volatile with each player fighting for a niche. I blame that clearly on the lack of technical insight into how BPM Systems should be build and offered to a development team.
In the past, the solution in the BPM industry was to broaden out to auxiliary functionalities such as
simulation, optimization and collaboration. I don't want to criticize those functions individually, but many BPM vendors even claim that you have to have all these in order to do something useful. I'ld say that's smoke and mirrors. A BPM runtime engine alone should be able to offer value and make sense standalone. If that's not the case, all the other auxiliary functions won't fix it. As
Peter Jones says (9:10): "That's stretching the brand as an elastic band. If you stretch it too far, the band breaks". BPM should go back to the basics: a runtime engine that runs executable business processes which are the result of a business-IT collaboration.
Instead of trying to exclude the developers from the equation in business-IT alignment, the BPM industry should think about what features the developers need in a BPM System so that the BPM System fits in their world also. Combining the software developers build with processes in a BPM System should painless. When the BPM System embeds seamless into the developers architecture, then developers can translate business changes faster and more effective into software updates.
