I came across an interesting discussion on LinkedIn which lead me to this post by Mark McGregor who asks, “…is BPMS now just becoming the next incarnation of application development”?
Our short answer is, “Yes…and the best way to get there is to minimize the disruption to application development.” In other words, BPMSs need to look and feel like previous-generation tools, all the while doing the right thing architecturally and automatically.
In short, it shouldn’t be necessary to teach old dogs new tricks. You simply swap in a new, improved dog in that looks and barks like the old dog…and the new dog’s “firmware” already knows about the new, modern tricks of app dev. (And I apologize for the tortured metaphor and to anyone horrified at the idea of swapping out Fido 1.0 for Fido 2.0.)
That’s what we are doing in ActiveVOS. Like your integrated development toolset for monolithic programs? We’ve got one that goes from modeling to deployment in a single tool. Holding on to that Turbo Pascal-like step/start/stop debugger? Ours works with services. Want to integrate with Java? REST calls? SOAP? Check, check and check.
Beyond just being familiar, for BPMS to become the next incarnation of application development, we believe there has to be a payoff for making the changes that using a BPMS requires. IOW, there are things that cannot be mapped to the previous experience — and which shouldn’t be. But a good BPMS still has to give application developers a reason to step up to the bar and change their habits.
For example, instead of coding, you model in a BPMS. Payoff? Learning BPMN 2.0. What else does an application developer get in return for allowing op codes to be pried from their cold, dead hands? How about automatic documentation plus resource simulation. The things that are new are really, really new and exciting…and worth the price of admission. That combo of familiar and enticingly new capabilities is what will attract developers and, ultimately, change the way apps are developed.
So, Mark has a really excellent point when he says that key BPMS players today include traditional app dev companies like IBM and Oracle. What Mark is hinting at is something we violently agree with: for BPM as a discipline to become the dominant way of creating apps, developers have to conclude that BPMSs are their primary development environments. Tools focused on end users won’t cut it for these developers. That’s why vendors like us have put so much effort and attention on app devs (how about we call them process developers?).
We (and they) know that until BPMS becomes the standard way in which new processes are created — companies that want the advantages of process thinking won’t get it.
CTO Tuesdays #15: Using Java with business processes [36:51m]: Download (101)
CTO Tuesdays #15: Using Java with business processes [37:00m]: Play Now | Play in Popup | Download (155)
CTO Tuesdays #15: Using Java with business processes [37:00m]: Download (46)
