The Promise of BPM: Easier for Developers, or Easier for the Business?
- August 2, 2010
- 1 Comments
Recently Bern Ruecker’s article on “A Collaborative Approach for Real-World BPM” appeared in InfoQ. It is a good read, with much I agree with and just a few things I don’t.
We have been working in the business process management (BPM) space for years already, and it is very interesting to see the recently growing attention for it. Catalysts for this interest may be the growing maturity of the tools, the new 2.0 version of the BPMN standard, better understanding caused by more publications or improved preconditions for BPM approaches, to name only a few of the most important developments within BPM.
Couldn’t have said it better myself. Bern goes on to criticize tools that they’ve worked with:
Vendors offer more and more high-sophisticated graphical tools, which promise automation of business processes without any coding or even developers; however, we see a problem with these “traditional” vendor centric approaches: They don’t deliver on these promises!
Agreed. But of course, most vendors don’t promise “no code” – but they do often claim that someone less than a true “developer” can deliver the solution. In my experience, while these tools do enable personnel with less technical training to participate in the process development effort, there is no such thing as someone “too technical” for a BPM project. Good technical help is important in any project involving information technology. He goes on:
Without naming the concrete tool, which wouldn’t be fair since most of them share the same basic problems, a colleague had to implement an easy process with a small web GUI. The tool introduced an own magic Drag and Drop GUI designer, which seemed to be handy in the beginning, but when we almost finished the project, there were some small data validation requirements in the form, which the magic tool wasn’t designed for. In an attempt to get around these limitations, we spent more time futzing with the designer than we needed to implement the entire GUI in plain JSF, which we did in the end anyway.
I can understand his feeling here. However, I have worked with at least one tool that has such a drag-and-drop GUI designer. It is great for prototyping UI, as it requires no code to marshal data into and out of the the process context on the server. There is also a validation framework that does just about everything imaginable for validation (but, admittedly, this validation framework is something only experts on the platform would know about). There’s also an option to validate forms after submitting (in the event that validation can only be accomplished with server-side checks or more complicated business rule evaluation). My concern with the statement above is, though it may be true for a single tool – a good understanding of the BPM software being employed, combined with good understanding of requirements, and with healthy value-based prioritization of work – should allow one to avoid rewriting the entire GUI in something like JSF. Of course, in Bern’s specific situation it may have been necessary, but I believe that on the whole we’re better of leveraging the baked in capabilities of a BPM suite rather than writing custom interfaces in JSF (or other UI tech). The exception being, if the customer is already an expert in the custom interface technology (already using JSF in their organization? great).
We, as BPM practitioners, have to keep in mind that it is not about the technology we’re most comfortable with, it is about technology our customers can consume, maintain, nourish, and build on.
Bern goes on with another anecdote:
For another customer, one developer told me, “It took more than two days to try to model some special requirements, which he could have written in Java directly in half an hour!”
I’ve heard this thousands of times. 9 out of 10 times, the developer is wrong, or missing the point. Once in a while, they’re right. But the point isn’t to bury the business model in Java code (wrong), or to put what should be Java code into the business model (missing the point), it is to use the model to represent what is significant to the business process, and to use code to represent (primarily) what isn’t.
Another customer tried to get transactions and stateful services running, which unfortunately required calling services as Web services. After experimenting with WS-Addressing, WS-AtomicTransaction and trying to patch several frameworks, he basically gave up and dumped the whole BPM tool.
I wish I knew which tool so that I can avoid it! A decent BPM tool should include good coverage of web services scenarios. And a Java API. Bern’s article is a cautionary tale of products that don’t live up to the promise of BPM.
Bern goes on to argue that a BPM tool should be making the developer’s job easier, not harder. While that may be true, I think the framing is wrong. The framing we would use is that a BPM tool should allow a model that accurately portrays the process to the business and also accurately represents the execution context required to run the process. If it is harder for the developer to provide visibility to the business, that’s secondary to producing something that has high-fidelity between business model and IT reality.
Bern goes on to describe a solution that he calls “Camunda Fox” – which pulls together various other technology, including JBoss, jBPM, Signavio, and a glue layer created by Camunda. It seems like a reasonable approach for a very technically competent team to tackle – especially a team that is intimately familiar with the technologies in question. But it is a model-transforming approach with several inputs and outputs. And this approach isn’t going to address the needs of a smaller business or smaller team that doesn’t have these technical skills, nor the budget to pay outside consultants to build and leverage this glue – I think Bern might argue that the “simpler” BPM tools won’t address these customers well either. As Bern says, Camunda Fox isn’t a silver bullet, but it addresses projects that are pretty Java development focused.
I prefer to use BPM tools with a model-preserving approach (as described by Keith Swenson) because it is a higher fidelity mapping of business process to running software.