Well, the Zero Code Hypothesis lives.? After posting about it recently, it sparked quite a bit of discussion on the post, and in twitter... and then the discussion leaped to other blogs.
First up, Alberto Manuel chimes in with a blog post:
In Scott?s post I argued that it?s possible to create applications on top of a business process system without any code, but using code offers much more design possibilities, as also, in most of the business environments it is mandatory you use code for solution delivery (otherwise it?s virtually impossible to implement).
Alberto points out that this would be a great conference topic - either as a bake-off competition between vendors, or leading to the next discussion:
What I think it?s also (most) important to the discussion, is as Scott pointed in a tweet, if zero code implementation is possible, and that kind of variant is at reach of business users, why it is not done?
This is a question I don't have the answer to.? Or at least, I don't have a definitive answer.? Alberto points out a few possibilities:
- The scope of the projects being too large and immediate (time to market)
- Business users don't have enough context about the implications of technological interconnections to make zero-code approach possible for enterprise scenarios.
I think item 2 is really a great insight. Item 1 was always on my radar, but item 2 dovetails with an observation that I've made quite a bit in recent years-? that IT professionals often know more about "how the business works" than business people.? Because often the business side of the house is just scratching the surface of what goes on, but IT understands all the interconnects between the systems and the organizations (internal/external) that technology enables.
Often in requirements meetings, the business proposes some process-scope, and it is the IT folks who actually know how that scope works today and become subject matter experts to vast parts of the business.? Ironically, many Fortune 500 companies have spent the last 15 years gutting their IT organizations as a "cost center" rather than treating them as invaluable sources of organizational knowledge and culture (and know-how).
But that's not all - Tim Stephenson wrote a post about bpmNEXT - "Simplifying BPM and the zero code hypothesis, themes from #BPMNext" - and he captures the discussion perfectly:
?Zero code? is often a short-hand for ?empowering ?real? users who are unfamiliar with code?. And that is both a worthy and necessary goal. After all, the days when a genius such as Isaac Newton could reach the pinnacle of several fields in one lifetime are long behind us. In the modern world we are all specialists. So if we believe BPM suites are powerful tools for managing our work then we need to strive to make them available to experts in all manner of fields. Let?s not give up on ?zero code? whilst acknowledging the limitations of our best efforts to date.
Of course, I'm biased that he said he agreed with my statement: "It looks like those of us writing code will have some work to do for a few more years yet."
This is a good argument as well:
Secondly, the best of these higher-level tools allow those that are coders to be dramatically more productive. This is why I got into BPM in the first place: rather than forcing users to cobble together a coherent workflow from spreadsheets, post-it notes and highly specialised desktop applications we can smoothly hand work from one person to the next and optimise whatever makes sense to within the clear boundary of a service task on a BPMN diagram.
By way of example, BPMN gives a "coder" the ability to draw a concurrent program with a diagram, while never once writing a semaphore or lock or synchronize.? The diagram is a much more reliable way to write concurrent programs, as it turns out, and much more productive.? I realize most people don't think of BPMN as a concurrent programming environment, but it is.
Also a nice shout-out from Tim regarding our Brazos UI framework- an attempt to make one corner of process development that much easier (and with better results).
Next up is the BPM.com Forums - where Peter Schooff borrowed my line and started a discussion: "We can characterize many of the sessions as targeting 'making BPM easier'? but more specifically, there were a subset of talks focused on delivering BPM without writing code."
The responses ranged from Steve Weissman to Jim Sinur, Theo Priestley to Keith Swenson, Patrick Lujan to Dr. Samarin. Heck, Keith turned his response into a whole blog post! And a good one, at that.
Most of the responses had a measure of agreement that while simplifying and easing the use of BPM was a goal, zero code was a bridge too far.? Still, there's always an outlier or two that thinks they have the holy grail for zero-code BPM.? Which keeps it interesting, and made it feel like my original blog post was trolling for just that response!