The Zero Code Hypothesis #bpmNEXT
Looking back at bpmNEXT, I’m already sifting and re-sifting through what I learned. After taking a step back, I think 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.
Let’s take a look at a few of those: Bryan Reale of Colosa/ProcessMaker, Tom Baeyens with Effektif, and Romeo Elias of Interneer, for example.
Sandy Kemsley covers the Colosa presentation in this post, but his presentation wasn’t necessarily all about mobile – it was all about giving up the notion of design time, and just letting users use the software:
What they are trying to do is increase adoption by reducing the effort required at design time by providing more ad hoc capabilities, with a resultant lower ROI but also lower cost. The result is FormSlider, an app environment for ad hoc workflow of structured data with minimal setup, which is what Brian demonstrated (still in alpha).
Brian understands that this approach has limitations, but he’s looking to solve the “viral adoption” or “organic adoption” problem, and then work back to solving harder problems later.
Tom Baeyens, founder of Effektif, has a similar (in theory) approach. No code required to build screens – and Effektif has a “five minute promise” that you can get productive with it in five minutes. No install (its in the cloud, like ProcessMaker). Tom is also looking to solve the adoption problem by reducing investment in the design time:
Tom’s premise is that BPM is just as useful as email, and it needs to be just as simple to use as email so that we are not reliant on a handful of power users inside an organization to make them work. To do this, we need to strip out features rather than add features, and reduce the barriers to trying it out by offering it in the cloud.
Tom’s one of the pioneers of BPM – and in particular, open source BPM. This new effort should be interesting.
Brian and Tom have some common challenges: adoption, minimum viable product, and keeping the products easy to use as features are added. A lot of complex problems are left as an exercise for later- migrating from one version of software to another, or one version of a process to another are just two examples.
The third entrant, Interneer, still had a strong emphasis on a model-driven development environment:
Interneer’s platform is intended to be used mostly in a drag-and-drop model-driven development environment. Romeo demonstrated creating a new application template that consisted of laying out a UI form for the mobile app using the full web interface (there could also have been a process attached, but the point of his demo was to show the mobile UI), then using it as an app on a tablet interface.
Several times, Romeo Elias emphasized that no code was required. While that was true in the demo, what was being done was sufficiently complicated as to be code. In other words, the amount of knowledge of the inner workings of a product is similar to what you need to know about an API. The complexity of building the app was significant but not overwhelmingly so. It just calls into question:
is someone who can’t write code going to be able to do this?
I don’t think so.
And that’s the problem with the zero-code hypothesis. For anything sufficiently complex, the design UI tends to be just as complicated as writing code – or at a minimum, too complex for non-coders to use, and too inefficient for coders to want to use.
And with the first two products, the problem is that when you run into the edges of what the product does, you’re stuck, because there really isn’t a design-time environment. By contrast, BP3’s approach with a UI builder is to use drag-and-drop only for the visual layout, which is hard to do with hand-coding HTML. Still, it was interesting to see three different approaches to the zero-code hypothesis. It looks like those of us writing code will have some work to do for a few more years yet.
A fourth option presented itself on Wednesday – Stefan’s demo for Kapow, of synthetic APIs. Philosophically, the point wasn’t necessarily to eliminate coding (after all, what are APIs if not programmable interfaces), but to eliminate tedious data manipulation (often done through code). For that reason I didn’t include Kapow in the consideration of the zero code hypthesis…