The Different Coding Levels of Process Automation in IBM BPM (No-Code, Low-Code, Programming)

The Different Coding Levels of Process Automation in IBM BPM (No-Code, Low-Code, Programming)

Published By : Brian French May 22, 2018

There has been a lot of interest and discussion over the last couple of years about Low-Code Platforms and Citizen Developers. While many of the big players in the Process Automation space have modified their message to include Low Code, IBM still hasn’t.  I thought I would take up the flag on this because IBM Business Process Manager (BPM) is a Low-Code environment. However, I also want to talk about No-Code and the flexibility to go from No-Code to other coding levels, i.e., to Low-Code to full-on programming.  

First, some definitions: 

No-Code: Interestingly, Wikipedia has no definition for No-Code development platforms, so we’ll use the definition from “No-code development platforms provide drag-and-drop tools that allow businesses to develop software quickly without coding. The platforms provide WYSIWYG editors and drag-and-drop components to quickly assemble and design applications. Both developers and non-developers can use these tools to practice rapid application development with customized workflows and functionality.” I will add to this definition that non-technical Business Analysts and even Business Users should be able to build a solution using a No-Code platform. 

Low-Code: Wikipedia defines Low-code development platforms as allowing “…the creation of application software through graphical user interfaces and configuration instead of traditional procedural computer programming… Low-code platforms reduce the amount of traditional hand-coding, enabling accelerated delivery of business applications. A common benefit is that a wider-range of people can contribute to the application’s development, not only those with more formal programming experience.” As far as what types of users is meant be “a wider-range”, in my opinion, this would stop at technical Business Analysts and not include non-technical Business Analysts and Business Users. 

Computer Programming (High-Code?): Wikipedia defines Computer programming as “a process that leads from an original formulation of a computing problem to executable computer programs. Programming involves activities such as analysis, developing understanding, generating algorithms, verification of requirements of algorithms including their correctness and resources consumption, and implementation (commonly referred to as coding[1][2]) of algorithms in a target programming language. Source code is written in one or more programming languages.” 

Now that we have a base to work from, let’s hone in on what IBM BPM has to offer here in terms of coding levels. In the No-Code space, IBM BPM does not have a story, other than through partners like Salient. Using the combination definition from G2 Crowd and myself, I don’t think anyone would argue a non-technical Business Analyst could use IBM BPM to create a working business application. I have been in the BPM space since 2005, and while it was always promised by vendors that non-technical business analysts could easily build executable process flows, the reality is most BPMS platforms (now called Digital Business/Process Automation), including IBM’s, offer so many possibilities that non-technical users are quickly overwhelmed. This is why Salient built our IBM BPM Quick Process Builder (QPB).  

In the Low-Code space, IBM BPM, and most Digital Business Automation (DBA) solutions, fit into the definition of “the creation of application software through graphical user interfaces instead of traditional procedural computer programming.” It certainly allows a wider range of people to contribute to building an executable workflow or business process. This is one of the reasons I fell in love with DBA type solutions back in 2005 while at Intel as their Business Process Management Enterprise Architect. It allowed people like me, who aren’t super technical, but can write some code, to build highly robust solutions that wouldn’t be possible without a DBA platform. However, it also allowed for getting as complex as needed by providing an environment in which people who are much more technical can provide the complex solutions many enterprise class business processes end up needing. 

Interestingly, while IBM’s competitors such as Appian, Bizagi, and Pega have done a good job of marketing their DBA solutions as Low-Code (in particular Appian), IBM has never marketed this at all for IBM BPM. I don’t know if it is an oversight on their part, or they feel their core customer (IBM’s core customer tends to be very large enterprises) isn’t interested in Low-Code. If that is the case, we certainly disagree with them. 

That brings us to Computer Programming, or what I call High-Code, development platforms. While IBM BPM does not qualify as strictly a High-Code development platform, the solution does allow for getting as complex as you need to build enterprise class executable workflows and business processes. A programmer can build out custom integrations via Java classes. The sky is the limit. However, with that flexibility, comes a price in complexity. There is the possibility of overwhelming less technical users. This is the blessing and the curse of having a swiss army knife type platform. You can do almost anything you want, but when developing more complex solutions, that freedom can lead to using the wrong approach unless you know the platform well. However, this is true of any situation in which you have many possible ways to do things. Experience is the key to being able to choose the right tool and approach. 

IBM BPM satisfies the Low-Code and High-Code spectrum of building solutions, but does not satisfy the No-Code part of the spectrum. This is the reason we created the SPARK Quick Process Builder for IBM BPM. We feel there is a need for business users to have a creative outlet to quickly build workflows. We want to give non-technical business users the ability to express their ideas, but in a guided context. Giving non-technical users this capability relieves tremendous pressure on an IT department because IT doesn’t have to build the solution. The business can go from concept to executing process without involving IT at all.  

What a No-Code solution like QPB does is allows non-technical people to express their ideas unambiguously. Salient essentially guides the non-technical user to capture their ideas effectively. We also deduce all that we possibly can without putting an unnecessary burden of complexity on the business user/analyst.  

However, we should not limit the possibilities just because the workflow was originally built using a No-Code solution. One of the typical limitations of No-Code solutions is they limit the user to only what can be built using the No-Code implementation. The resulting solutions are not scalable so they can be used in the Low-Code/High-Code BPM environment to be extended to handle more complexity over time. When Salient created QPB, one of our guiding principles was the application created by QPB must be a fully functioning process application that could be extended using IBM BPM if need be. Thus, a non-technical business user could create, deploy and run a process application on their own. However, they could also hand over the process they’ve built to IT, once more complex development and integrations were needed, so the solution could be extended.  

So, what we have with QPB is the ability to go from No-Code up to other coding levels – Low-Code and  full on computer programming. When you add QPB on top of IBM BPM, you end up with incredible flexibility and are now able to attack a problem in many ways. You can have your business develop the initial solution, and when more is needed, get IT involved to extend the solution to handle much more complex scenarios. What Salient is giving you is the freedom to choose. (READ: The Journey to No-Code Business Process Improvement)