My very first BPMS Watch column, over three years ago, was titled “Without a BPMS, It’s Not Really BPM.” And to a large degree I still believe that, although today I would probably tone it down to something like “without a BPMS, you can’t realize all the benefits of BPM.” That view is certainly less radical now than it was in 2005, as both developers and developer-oriented tool vendors have increasingly embraced the BPM Suite idea. But BPMS still has enemies, both real and imagined, and some of those long-simmering tensions boiled over this week on my BPMS Watch blog.
It’s an issue worth acknowledging. (To get into all the name-calling throwdowns, you need to go to the blog.)
First, what is a BPMS? It began as a Gartner term meaning an integrated suite of tools and runtime components for modeling and implementing BPM solutions, including human workflow, application integration, business rules, and BAM. The marketing word “suite” correctly suggests an all-in-one offering from a single vendor, as opposed to a stack of plug-and-play components. While to some this screams “vendor lock-in!” such a unified environment is crucial to BPMS’s – and I actually think BPM’s – central promise of business empowerment.
Business empowerment in the BPM context does not mean business users are building executable solutions without IT involvement. It actually means that process modeling – inherently a business-driven activity – does not just generate a business requirements document handed off to IT, but generates skeleton artifacts of the executable solution fleshed out by IT. Thus BPMS also stands for a new agile iterative implementation style in which business and IT collaborate throughout the process lifecycle. Collaboration around artifacts shared by business and IT demands a visual “language” usable by both, and the success of OMG’s Business Process Modeling Notation (BPMN) standard is largely due to its ability to provide that language. In addition, the process design tools used by IT to turn the models into executable artifacts – automated activity flows, task user interfaces, business rules, BAM KPIs and dashboards – are mostly point-and-click, not code. As with BPMN, a bit of design freedom is traded off for a giant increase in agility.
This is all background to the recent shouting. It began when an architect/blogger denounced what he calls “automated BPM” – I would call it BPMS – as a “nutty idea” because it promises that business “can give end users one of our pretty languages (BPMN or BPEL) and they will write their own software, and we can fire all the IT developers.” But this is a bogus strawman argument. BPMS makes no such claim, and I challenged the blogger to produce some evidence that it does. And, no surprise, he could not.
He then retreated to a fallback position, which is that even with IT involvement in the implementation, building solutions using one of BPM’s “pretty languages” was a fool’s errand – growing rice in the desert, as he called it. “The conditions in most IT shops are comparable to the desert…. {But] creating an environment where BPM is a good thing, where true flexibility is achieved, requires creating the fertile soil, and plentiful water, and ample shade, and skilled workers.” Consequently, “any IT department that wishes to delay an investment in BPM, because they need to first invest in data security, or network reliability, or application integration, or improved business efficiency, or better user experience, is well advised to do so, because most of those things will provide more value, in both the short and long term.”
People with this viewpoint – and there are a lot of them – could fairly be called enemies of BPM. In reality, BPM does not claim to be the solution to every business (or IT) problem, and for the most part it delivers on what it actually promises. So who is threatened by it, and why? One group is a subset of developers and architects to whom the slightest whiff of business empowerment in solution implementation – even in the limited way offered by BPMS today – poses a frightening challenge to their traditional authority and independence. In this extreme world, apparently even BPEL can be viewed as a business-inspired threat to “real” developers. And the all-in-one suite idea is also anathema to the architect’s ideal of a stack of plug-and-play standards-based components, just an insidious way for vendors to make money.
While fending off the enemies of BPM on one front, I was surprised to hear about a new set of enemies… and the suggestion I was siding (innocently, I hope) with the bad guys. The issue this time is the contest over BPMN 2.0, which pits a longtime OMG project called BPDM against a joint submission by IBM, SAP, and Oracle. BPDM is an abstract metamodel for all process description languages, not just BPMN, and aims to provide an extensible foundation for future versions of BPMN. The proposal is written in a computer-sciencese incomprehensible to most BPMN users, and has been accused (justly I think) of being “complex.” I would call it almost incomprehensible.
The IBM-SAP-Oracle proposal is much closer to today’s BPMN, adding an XML interchange format. BPDM’s authors and supporters are mostly not BPMS vendors. The authors of the other proposal are, and their proposal reflects (to me, at least) a continuation of the ideas that have made BPMN so successful in the BPMS world to date… even without an interchange format. But now a BPDM supporter, someone I deeply respect, turns that “complexity” charge on its head, arguing that IBM, SAP, and Oracle are in reality trying to dumb down BPMN 2.0 in order to “kill BPM,” in particular its ability to empower business.Those vendors all came late to the BPMN party, and their BPM tools today do fall on the architect/developer-oriented end of the BPMS scale. “Could it be that they recognize that crippling the power of an alternative model to UML might be in their strategic interest?” asks the BPDMer. “We want to move business modeling forward. Why would we spend 18 months doing what can be done today perfectly well with BPMN and XPDL…. Instead they’re stealing time… trying to get us to wait until yesterday gets here.”
I don’t buy the conspiracy theory. Maybe I’m naïve, but I think these vendors are acknowledging they made a mistake by too long ignoring BPMS’s agile/iterative implementation style based on business-IT collaboration. There is still room for legitimate differences of opinion, but I understand that commercial interests do influence standards.
The bottom line is this. BPM, and in particular its promise of business-empowerment, is a disruptive idea. We should admit it and embrace it, not sweep it under the rug. BPMS, and BPMN’s role in business-IT collaboration, is an inherent part of that promise. It threatens traditional IT practices and reshuffles the deck on roles and responsibilities – in business as well as IT. Thus BPM does have enemies, and we need to acknowlege that as well. We need to expose the false charges and educate the uninformed.
We can be ever vigilant and slay the enemies, but let’s not forget the civilians. There is still a battle for hearts and minds that is not yet won.
