The Zero Code Hypothesis #bpmNEXT part 2

Scott Francis, posted a quite relevant post after coming out of BPM Next Conference about the possibility of developing and deploying process applications with a “zero code” approach and how that can turn out to be very limiting when a company is designing applications of top of Business Process Systems.

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).

I consider Scott’s post relevant, because this is the kind of discussion that most of the times are not included in conference agendas or do not make part of the discussions inside the community, once everyone likes to talk about the implementation success (that was done taking the thorns off the skin, sweating and screaming), when we should talk about how to guarantee success in process improvement initiatives, in a time were most of the customers are facing a trade off about cutting budget and try do implementation by themselves, with the promise that the system they bought allows with some hours of training make knowledge transfer, or, in the other hand, pay a huge amount of professional services fees to minimize the risk of the project.

Lately with the promise of the rise of knowledge workers  I took care of projects that followed the former approach that have resulted in very poor implementations, simply because the customer over evaluated the skills of it’s own team, and they could not deliver what they committed to (like for example diagramming BPMN 2.0 processes).

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?


The Zero Code Hypothesis #bpmNEXT twitter stream

The Zero Code Hypothesis #bpmNEXT twitter stream

I think there are two reasons for that:

  • The first, is the scope of the projects. There is always a learning curve to transfer knowledge to the business users, factors like, we need to ramp up fast, we cannot wait to put it up and running by ourselves after a pilot of two, because we are going to loose market opportunities and operations need to resume to business as usual instead of developing applications during the day and perform the daily work during the night. This aspect is starting slowing to change, as more qualified workforce have the skills to put their hands on the tools, but still, it can turns out something like when you have a business intelligence project and you find in the customers team someone that did some good stuff based on ad-hoc sql queries and created some excel files with pivot tables and charts. This kind of approach, knowledge transfer, implies that your customer have a very strong team with governance guidelines, that have a huge experience in process improvement programs, that most of the times does not exist. Hence, in the end it’s cheaper and more effective to pay the professional fees to the provider, rather than take the risk and try to do implement internally. This variant also includes the fact that most of the customers are not experienced in process engineering, meaning that even if they master to use a BPM system they will fail how to design an optimized process operation, that simply laying down technology will not (also) make it.
  • The other factor is the doom business people experience when talking about the other side of process implementation, technology. Like the turf wars about business architecture and technological architecture, business users, even the most experienced, only scratch the surface (they do scratch because it’s out of their domain expertise, it’s a cognitive limitation) when they need to understand the implications and technological interconnections, that makes virtually impossible, by themselves, to implement a “zero code” approach. If the in the future semantic oriented design starts making part of the enterprise architecture and tooling, probably it can be possible to reach this outcome.

This is the kind of discussion I think it’s worth to have and help managers to reach successful outcomes, and I apologize to Scott to tweet that his post should not be buried in a blog post (like this one). 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.

What are your thoughts?


6 thoughts on “The Zero Code Hypothesis #bpmNEXT part 2

  1. Alberto, if you like it or not or regardless whether users feel intimidated or not by technology, the solution to complexity is technology. I use the iPhone and Appstore/iTunes ecosystem as an example. EVERYONE can use the underlying VERY complex technology and it empowers both the developers and the non-technical endusers in a fantastic way. Try the same on Android and you will see the dramatic difference. I covered this in a blog post years ago: ‘Teh Complexity of Simplicity.’ –

    Business users should not be worrying about BPM technology at all. To them it all must happen in their own business terminology. The engineers and consultants job is to make that happen. Unfortunately they are sustaining their own jobs by not making it simple but by keeping it complex and by remaining the ‘BPM gods in suit and tie’.

    This is what I posted in to a similar question:
    “The claims that business users are enabled to design processes with all kind of graphical tools and 6th generation languages are empty. They simply aren’t. The point is that business users already have a tool to design processes and it is their business language using their business terminology. So unless the BPM environment allows the definition of a business language ontology that ensures that whatever function is presented to the user on the UI is in their language without ambiguity, all BPM functions are too complex for the business user.

    For creating the user interaction, the system should support the creation via user stories in the form: ‘As a claims clerk, I want to list all damages so I can assign the right assessor.’ That represents a ‘context’ in which ‘actions’ are taken. To support the unpredictable side of processes one must be able to define which ‘events’ can happen. All in business language. Unfortunately some of it will require logic and thus a kind of rules language and yes, there is a lot of room for improvement that an ontology brings to rules writing. But yes, defining steps, data dependencies, rules, context and actions/events is also a form of ‘coding’ and boolean logic simply is not for everyone.

    Therefore as much of the logic of a process should be INFERRED by the system through learning from what users are doing in the real process and not what some disconnected process expert thinks the process should be like. I call that a machine-learning agent.

    So for me the following things bring process management closer to the business user:

    1) A business language ontology (created by an analyst … with data entities supported by IT).
    2) Processes are defined top-down by goals, outcomes and handovers using the business ontology.
    3) The user interaction is described through context/action user stories.
    4) Processes are created by the business users by adding tasks, dependencies, content and data in their language.
    5) A machine-learning agent makes suggestions learned from user actions, (users can tell the agent he is wrong!)
    6) As processes are being refined by whoever is skilled enough, they can add guiding or limiting rules using the ontology.
    7) Any completed process or parts thereof can be saved as goal-achieving templates.

    It is the underlying complicatedness of the technology that makes the functionality simple enough for the business user. Simple technology is mostly not simple to use. BPM flow-diagrams are way to basic as technology to be practical for a non-engineer.

    A process management solution needs the ability to let business create its processes as otherwise these processes will also just be complicated and never represent the real-world complexity of a business and its consumer/customer interaction.”

    • Hi Max:

      I perfectly understand your point of view and the architecture principles you enumerate towards a “code free” environment. In the past I also made reflections about it and I believe that in the future it can be possible to adopt such an approach. There still some important points to consider.

      One and probably the this is the one that have most negative influence is the presence of legacy systems in companies like Banks, Oil&Gas, Utilities and Airport Management. It’s impossible upfront do cleanse the IT architecture landscape of those systems. For example. if a bank makes an investment in a generic BPMS, it’s very unlikely that out of the box providers connectors to the proprietary systems of the bank to check signatures, once these kind of systems are typically developed / evolved by internal teams from a scratch or on top of a base configuration if it was bought under commercial licenses. This means that coding is necessary to enable such interoperability. In Oil&Gas, the land of closed systems, the same applies if we want to integrate signals from refinery equipments in maintenance management (as so forth in the Utilities and Airport Management industries).

      The second factor is human and probably one of the most difficult to eradicate. People love change, but don’t want his personality, his beliefs to be changed. Some people think (this is a very personal point of view) it’s best to secure it’s place trying to control change. In the long run, they are transforming into a disposable asset that it’s to late to realize when the times come to send them home. Until that day arrives, these “civilized people” will invoke a never ending rhetoric, that despite all the enthusiasm created, the company it is not yet prepared for a change, because they now they cannot give up control of the enabler of their position in the hierarchy. The attitude only changes when the organization is threatened (and it can be to late) or when a new manager with passion (that the “civilized people” and psychologists like to classify with emotional instability) implement a new paradigm.

      New paradigm is the third factor. When we look to what consumer wide social technology is today, we see Facebook trying to catch up by acquisitions, like the deal with WhatsApp. Facebook was build in the Pre Mobile / Cloud era. It was developed to be used on a desktop / laptop and despite it still have a huge user base and it’s value it’s about the priceless data it stores about what we do and our living and consumer habits, it is lagging in user experience because it’s architecture does not cope with the new interface requirements and devices were it runs. New paradigms (like the ones Apple implemented) are the most disruptive force companies have to fight with. Cloud, open source, co-creation, co-funding, new generations that were not taught on old school management lectures and the fact that in some business it’s not necessary to have access upfront to huge amount of capital to incorporate a company, results that from the middle of nowhere you have a competitor in your space. And because the business model, even if it can be copied, sits in a radically different approach, incumbents need to make a titanic effort to redesign operations if they want to match or overcome new entrants.

      Still, I do see that it is possible that instead of “singularity is near”, efforts that are being done in different communities about interoperability, IT design and deployment simplification. New approaches based on semantics, ontologies, internet of things can slowly in the future bring the promise of “zero code” a reality, but I also should point out, that such kind of IT architecture transformation needs to be driven by a management team that creates such a vision. It’s not only the CIO that is going to bake it. It’s a full set of managers that want to make that result happen. This is, I should say the most important factor, but also I would like to add that this the kind of challenge I like to address.

      • Yes, Alberto. I wrote ten years ago: ‘Agility is a human property and not a feature of BPM.’

        In these days software is either an enabler or a disabler (like old silos) of change. the impact of technology is actually pretty immense despite the human factor.

  2. I feel like there’s a parallel between the complexity of technology and Max’s responses in blog posts 🙂
    I need the iPhone version of Max’s posts until after I’ve had coffee 😉

    I think you’re right Alberto, it is an interesting question. I mean, honestly, take BPM out of the equation. When there are good no-code tools for building software, still, most people in business don’t use them. Would be interesting to truly understand why, rather than assume. Some of these tools are quite good. Oh sure they don’t necessarily integrate to SAP or whatever but set that aside for the moment- we need to answer the first question before a “no-code” integration to ERP even enters the conversation imho.

    • Honestly, Scott, not sure what technology you are using to read what I am writing because a lot seems to get lost. 😉

      I am clearly distnguishing between setup/integration and what non-technical business users get to create and support processes. There are no zero code tools for both. There is for example no programming needed to link to most SOAP and REST interfaces in Papyrus but it is not for the business user because of the involved logic and who cares. You do it once. But a business user can now without IT and months of training create a new case/process and chose to use any of the prepared data sources using the business terminology that he is used to. Given the proper setup they can even create custom user interaction based on user stories or context/action. No experts needed to design or improve processes.

      Demanding simplicity in creating applications will never produce simple applications for the user which is really what information technology is all about. Maybe businesses shouldn’t have gotten rid of all their IT people and outsourced it all?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s