if you can avoid coding (and in my opinion HTML, Javascript and all that proprietary script inside a BPM tool is code) do so. Code makes BPM solutions brittle, and hard for business users to update in the future.The developers of BPM solutions have done a good job of providing process design tools and execution engines around the process flow. Unfortunately, the likes of Intalio, clutter their core idea with attempts at being a total application development system and fail. Even HelloWorld examples get cluttered with XPATH, SQL, XFORMS and Javascript.
BPM solutions seem to have been accidentally painted as an alternative to disciplined development and lessons painfully learned in IT-shops are having to be relearned.
It would be nice to see BPM solutions architected with clear separation between presentation, data-handling, business decisions, rules and process flow logic. Coding is required somewhere along the way but we should all understand where and who is responsible for it.
3 comments:
Very much agree with you David. What's the point of having a BPM tool that requires a high degree of development skill. There's a place for that in all phases of implementing and managing your BPMS, but counter to the purpose of the tool to ask for this before it's needed (or in the case of Intalio and so many others, during the entire process of running the
BPMS). Full disclosure, I'm helping a company called Active Endpoints - their ActiveVOS suite strongly features human workflow as part of the the entire business process framework. I think that is part and parcel of what your blog is getting at.
Hi David,
I've been involved for many years in the development team of a BPMS named Bonita. And I agree with you when you point out that technical skills are needed to use some BPMSs, even to design very basic processes. This is why we developed Bonita into Bonita Open Solution 5.x. We are trying to make all phases of a process based application deployment as easy as possible. We have reduced coding needs, so only very technical requirements like solution extension need coding, and very little of it. Even for these kinds of requirements, we have found ways to reduce the code complexity. This is a major issue today with BPMS and a real technical challenge to make it easier. Today even managers, non technical people can design and deploy processes with an open source solution!
Regards, Rodrigue
I completely agree. Interstage BPM represent a process in terms of responsibility of the people involved. The entire diagram of flow of responsibility (not data!) can be mapped out and approved. Then, code can be added in separate chunks called "actions" which are either in the prologue fo teh activity, or the epilogue of an activity. This clear distinction between the responsibility flow, and the programming has helped emmensely in process definition re-use.
Post a Comment