Tom Baeyens (from jBPM) wrote an interesting article about the over-promises of some BPMS (Business Process Management System) vendors.
His dicussion addresses two points:
- BPM vendors often overpromise by hinting that BPM tools can unify analysis with implementation
- Lack of integration between processes and plain general purpose programming language
From my experience with Fuego (now BEA AquaLogic BPM) it's safe to say that it doesn't fall in that category. I don't know what vendors he's referring to because, honestly, I've never spent serious time trying or analyzing other BPM vendor products.
On point #1: BPM over-promises
Tom is on the camp that any serious BPM development (or any "software development" for that matter) will always require a developer. He believes that the case where a Business Analyst defines and deploys a business process without help from developers is limited to BPM vendor demos.
Keith Swenson, on the other side, replied suggesting that BPM could be like Spreadsheets: many business people now use Excel to build their own software solutions without help from developers.
Both arguments have their merits, and I think reality is somewhere in between.
From my experience building BPM solutions for customers, I believe that the ideal of complete IT independence is not feasible today, nor in the near future, except for very simple cases. (not only because of technical, but also cultural reasons).
I'd question that the Spreadsheet example, while interesting, is quite simplistic. What a business analyst can build with a spreadsheet is a lot simpler that what you'd normally need a BPM for. For instance, a spreadsheet "application":
- is a single-user solution
- Has no concurrency
- No security requirements
- No integration with other system (or minimal integration with a database)
- No transactionality
- Does not "expose" functionality to other systems
- No "enterprise" deployment (just run it in your desktop)
Obviously, you can build a single-user, non-transactional, non-integrated solution with a BPM tool, and yes, a non-developer could do it. But you'd be falling into the toy-example case that Tom hates about BPM demos.
But, I do believe that with a good BPM tool the level of abstraction can be raised so that less technical skills are required to build usable solutions. And, over time, that level will be raised more and more. I've seen business people that, after being involved in a couple of BPM projects, they do more and more by themselves, to the point of building robust usable prototypes on their own.
On point #2: Process and general programming languages
With point #2 of Tom's original post, he states that it's critical to integrate the process model with a general purpose programming language.
I feel comfortable with that idea, because that's how it's been done in FuegoBPM (ALBPM) since day one. And although I cannot say it is the best approach (since, again, I have no real experience with other BPM tools), I can testify that it works pretty well in practice.
As a side note, we believe that it is bad practice to overload the graphical representation with massive amount of decorations to try and express every little technical detail of the process. But the most important point is that you can create a common language between the technical developer, who is responsible for making the process executable and the business analyst, who is responsible for communicating the requirements.
I agree with this, and it's important. The graphical process design should be at a high-level of abstraction, in the business domain terms, so that anybody can understand and follow the business process flow.
I think the value is not on the fact that a Business Analyst can design an implement a solution on his own. Instead, the value is that the Business Analyst can build initial designs and prototypes, and then keep participating on the process design during the whole development lifecycle, because while developers implement the low-level details, the graphical model (if done right) is still understandable by everyone. And, this graphical model is not just documentation, it's the real thing, executable.
As a side-effect, BPM is a great tool for facilitating iterative development, helping to close the communication gap between the business owners/users and developers, allowing early and continuous feedback into the development process.