The Zero Code Hypothesis #bpmNEXT

Scott Francis
Next Post
Previous Post

bpmNEXTLooking 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…

  • DavidChassels

    All seem to be approaching from a technical point of view? BUT it needs a business driven one. It is what we started over 20 years ago and we recognised that business logic never changes – it’s people doing things and need supported and we “discovered” less that 13 work task types human and system address all business logic! So code only once as generic and allow easy configuration – we built a Graphical Process Designer to allow easy build AFTER we built core capability.

    http://www.igi-global.com/chapter/object-model-development-engineering/78620
    This research paper tells all and of course more added to cope with web and legacy orchestration from the UI. Very simple builds any thing and NO coders! A Business analyst can now build direct with users. IT is in “support” to help with complex calculations, “legacy” and of course secure reliable delivery BUT it is always driven by business people in their language!

    Good to see at last others now recognise the need – it has
    been a long lonely journey but with a huge global contract to build all systems
    supporting global distribution of humanitarian funds with this “BPM” approach
    will put this on the map…….at last!

    • David, appreciate the comment, but you really should have attended the conference before painting with a broad brush. In some cases, these are new entrants to the “zero code” approach, but that approach has been around since the beginning of BPM, and continues to have the same challenges it had then.

      • DavidChassels

        Yes but it was long way to travel as we line up our global
        funding! My broad brush is from impressions on emerging comments and none quite got the simplicity covering all business needs as discussed in BPM Forum. That appears to be the challenge that we addressed and resolved…?

        We started our R&D long before BPM appeared the driver was to fix the enterprise software problem to find a way to build applications reflecting how business actually works and remove programmers from build! The “challenge” on the technology solution we found and so simple yet handles any business complexity. BUT the market is the biggest challenge where “IT” just struggle to “get it” with huge vested interests not to “believe”!

        Mahatma Gandhi articulated on human reaction to something “new”“First they ignore you, then they ridicule you then they fight you, then you win” Business people get it very quickly but with IT we have had plenty ridicule and being “ignored” including by the big analysts? So now we prepare a new model to distribute with “global
        backing”. USA is not our primary target market as we focus on South and East. Happy to do innovative “code” deals it will take apart likes of IBM old tech approach and as BPMN slides into history we open a new door and happy to share.- it all about the customer or should be

      • David, honestly, I don’t even know what you’re talking about in this comment?

  • Alberto Manuel

    Scott:

    I tend to disagree with your point of view. I would like to say for the record I am partner of BP Logix, a company that promise to deliver process applications without code and as a matter of fact attended this year BPM next.

    By professional experience I built process applications using BP Logix’s Process Director, able to play the full process spectrum, with parts of the process structured, parts of the process not structured built using what is called process timeline. But let’s put aside the endorsement and get back to the trade off of building process applications without code.

    Code offer unlimited possibilities of design it breaks all the barriers and frontiers but it increases the combination and design complexity. Ultimately can point to design doom, like project scope creep.

    On the other hand, imposing as a design constraint that is not possible to code, limit your design options and creativity, but enables to a clean and lean design.

    • I’ve seen gantt charts sufficiently complicated to maintain with dependencies and what not to refer to as a coding exercise. The issue is, what’s the best way to manage complexity or remove complexity. When a gantt chart or timeline view is the best view for a problem, it is likely because that view simplifies or reduces the amount of code involved, and the complexity. But when it isn’t the right view/lens, you’d see increasing complexity rather than decreasing.

      Diagramming BPMN (or any diagramming) can be just as complex as code, when sufficiently large systems are modeled. Once something requires a sufficient amount of abstract thinking, i think it enters the realm of “not terribly interesting to the business users” that it is allegedly targeted at.

      • Alberto Manuel

        Scott:

        I do not want to enter into those never ending discussion. I believe simplicity. As someone like me that comes from a country with limited resources at hand, me and my teams make the most of the available resources independently if is BPMN ( that cannot cope with diversity and complexity) or any other means available.

        Let me put a challenge to you: in order to evaluate the best solution in independent events like BPM next or BPM conference Portugal (that I chair ) it should be conceived a challenge to the system vendors. The best solution wins (like in the gladiator era). That way it was possible to evaluate what the best design was and in this particular discussion if the best app is code less , or not.

        Best

        Alberto.

      • Alberto- I’ve been around for 3 generations of “no code” (at least). No one tries to sell swamp land to a guy living in Florida. Don’t try to sell a fellow BPM expert on “no code”- I’ve heard it all before 1000 times.

        I don’t know anyone without a product to sell that is pitching no-code for BPM as the answer. Let me know when you find that person and I’d like to talk to them and see what they think :)

        I’m just trying to solve problems for customers and I’ve seen this “no code” promise broken so many times there’s glass everywhere!

      • Alberto Manuel

        Hi Scott:

        I think this discussion is so relevant that I created a small blog post about it here: http://ultrabpm.wordpress.com/2014/04/09/the-zero-code-hypothesis-bpmnext-part-2/

        The challenge it’s to promote this discussion to a conference session or
        an independent webinar, but probably system vendors are not keen to
        talk about. Something like the spirit of BPM Next can slowly start to
        change.

      • having said all that, a demo competition would be fun, just not sure the vendors will sign up – lots of argument over scenario/etc. i’m sure :)

  • Pingback: Simplifying BPM and the zero code hypothesis, themes from #BPMNext | Know Process()

  • Pingback: The Zero Code Hypothesis #bpmNEXT part 2 | End to End BPM()

  • Pingback: Effektif at bpmNEXT | Effektif()

  • KDS

    Completely agree that designing is coding, and coding is designing. You can’t separate them, and anyone claiming that you can design a system without coding is probably selling you something, and it doesn’t smell good.

    However, there are systems that don’t need designing. http://social-biz.org/2014/04/15/zero-code-bpm-systems/

    • Not all promises of “zero coding” are made equal. Some drag-and-drop is actually “more efficient” than writing symbols that we call “code” – but that doesn’t mean that a series of 40 dialogs and config screens isn’t “coding” :) The question is how much arcane knowledge and abstract thinking do you have to use :)

      like your post, it’s a good one.