It's not appropriate when it's sold as an 'any business user can create apps' type solution. Regardless of how easy it is to use and create forms etc you still need to have an analytical mind and an understanding of how information flows to create an effective solution. If sold in this way it can just create confusion, mistakes and cost more than any benefits.
You have better options than low-code BPM when the following are true.
If you don’t have hundreds of thousands available (to start with), then a low code solution may be the only affordable option. Or spreadsheets.
If you can use a generic user interface, or you don’t have to automate everything, or you can get started without complete systems integration, then you may well be able to achieve some business value without (someone) writing a lot of code.
If you know exactly what kind of process management and automation you need, and your change management initiative is already complete, then you might as well build a process management system, instead of using something simpler to figure out what you need. Otherwise, start with the sticky notes, then move on to a low code system, before later going for a classic full BPMS.
Of course, even if you really are in this situation, your other options might not actually bebetter.
Taking the question at face value, how about "never"?
The cost of coding is wildly underestimated. For business process automation, low-code, or better still, zero-code, is the target. And we're almost there.
In the meantime, it's worthwhile looking at what's outside the Venn diagram bubble of "business process automation". We don't want to muddy the argument.
1. SOA CODE -- We should exclude from our question so-called "execution" code. Per Volker Stiehl's argument, with a proper systems architecture ESB and SOA "coding" is segregated from process business logic, which can be deployed from executable BPMN.
2. ALGORITHMS & RULES -- Let's also exclude from "coding" legitimate uses of code which are external to what we are after, which is business process automation. Specifying an algorithm or a business rule is not "coding" per se, they are a formalization of business logic.
3. USER INTERFACE -- And UI coding is also not coding strictly related to business process. (And even UI platforms are getting more and more powerful in terms of reduced need for coding.)
Notice the initial "never" is qualified by "almost". To be able to execute any sensible arbitrary business process is what management needs. Most BPM products still have problems with some complex process graphs, which in those circumstances require a little coding for messaging. This is unfortunate. Better math in the BPM engine would help. But in most cases, avoid code.
Low code is not an option UNTIL you have a clear understanding of the business processes and you have Simplified and Optimized them. Only then should you Automate. Otherwise you are simply spending money to "do the same shit, only faster"
Jim Sinur just published a blog post about "Simplify & Automate"
As always, I look at BPM (yeah, not BPMS) from the business side. So you will not be surprised tha my answer is "as less as possible" .
But when you think you need a BPMS (I think the 's' is missing in the question) to support the executing and managing of your processes, I would prefer it is as easy as possible.
15 years ago, at Pallas Athena, we had a process modeling tool and a very complex Case management tool.
Then we decided to make an in between product, where your process model could be "brought alive"
This was already a little step towards lower code. I used it with nurses and they loved it. Not because it looked well, but because the picture became reality. Live in the room. It created so much more process understanding than looking at 'blocks and arrows' .
So at that time it was absolutely cool for prototyping.
But, when brought live you still needed some coding/scripting to connect, for example, with data sources.
But as we know, there are some CEO's of low code app vendors that will solve it for us ;-)
Also another thing not to forget; there are many types of processes (straight through, goal driven ,etc). So first start with a proper understanding what kind of support your processes need and then find the lowest code as possible.
It is when I flip the question on its head ("when is the low code BPM the best solution?") that I struggle to find an answer...
I want to love low-code solutions - in my unusual quest as a tech-loving CFO, I tried a huge number of them, not only in the pure BPM space, but also in CRM, on-line database management, note-taking, collaboration, filesharing, project management - including purely mobile solutions as well.
Few stuck to my workflow. Most of them, despite being highly proficient on their own terms, didn't.
So, some of these tools are useful as long as they address a particular unmet workflow need in a very specific, peculiar way. They are usually oblivious to the overall customer-mandated goal of a business process - they just fix a small task or an immediate set of tasks (if we're talking teams).
Low-code BPM solutions struggle heavily to meet the demands placed on them by serious, long-term running, business processes. It's fun to draw some user forms, and color the buttons and send some automated emails, but frankly that's not an business application:
- it does not have a proper underlying architecture - data, integration layer with other systems, validation by business rules, coordinated with other business players etc.
- since it's most likely not mandated / deployed by IT, it's probably not widely shared in the organization - it's just a collection of personal hacks, not documented, only sparsely managed and maintained.
So, I'd conclude that low-code solutions are only suited for personal / team efficiency purposes. But that's just such a small subsidiary goal of BPM, that you simply do not need BPM-focused tools to achieve those.
All business logic is prebuilt for quick build with easy configuration. Basic understanding of data base set up helpful but not coding. However there maybe need for complex manipulation of data support as an algorithm and here clever custom coding might be best bet. Howevesr this specific reguirement works directly under direction of the business driver.
Low-code, rapid application development is generally going to be preferable when the alternative is traditional, code-intensive, long-term application development. That's a pretty obvious statement, but not entirely helpful. It's rather like asking, “Which is preferable—the express train, or the local?” The worldwide economy rests upon this assumption: All else being equal, faster is better, cheaper is better.
I don't agree with John's point about UIs. Build any UI you like, but you can still drive its behavior with BPM. Still, there are certainly applications for traditional coding, including:
Interesting, actually: those two cases are at the opposite ends of the criticality axis, leaving me wondering if the applicability of BPM to the universe of automation needs comprises a normal distribution. Are about 68% of applications whose criticality is within one standard deviation of the norm excellent fits for BPM, with the fitness decreasing as criticality increases or decreases from that point?
Meh. Ignore me. My kid is taking stats. Last quarter he took astronomy and I kept wondering if the demand for BPM could be explained by multi-body gravitational dynamics*.
*) Spoiler: No, it cannot.
Minor update to deleted posting . . .
Difficult question as BPM continues to be different things to different people.
I read over “What is BPM?” and one key definition that needs to be kept in the forefront when commenting on low-code (of what?) seems to be:
“Implementation (coding) of the process application is not BPM - An application developer designing a form for data entry as a step in a process is not doing BPM at that moment. Once the “to-be” process has been adequately spelled out, the actual implementation of the application that supports it is no longer actively engaged in improving the process. A small caution here: applications are often developed incrementally — show to the customer, get feedback, improve, and iterate — and the process may be improved incrementally as well. Those incremental improvements should be included as the activity of BPM, but the activity of implementation of the application is not BPM. The criteria is clear: if you are actively and primarily engaged in improvement of the process, then it is BPM, otherwise it is engineering”.
- Not data collection forms at BPM steps
- Not actual implementation of the app that supports BPM
- Not run-time execution of BPM template instances in, perhaps, an Adaptive Case Management app.
Looks like low-code BPM refers to coding in the process mapping environment, exclusive of the design of data collection forms (as above) that process mappers park at steps and exclusive of the design of rule sets that may be embedded in forms (given that forms design is not BPM).
Likewise, application development (e.g. the run-time environment hosting BPM templates\instances and the UI for the run-time environment) is not BPM.
This leaves low coding needed within the mapping UI and rule set “code” needed at branching decision boxes in process maps.
I can’t think of any other need for “coding” when mapping processes so the entire focus of low code seems to go to rule sets at branching decision boxes and rule sets at loopback constructs.
An expanded list of perceived coding needs from readers would be helpful.
Within the mapping environment we can add that in respect of complex algorithms, someone has to do coding somewhere.
The options are to use some computer language that allows you to invent a new process step that performs the required calculations but why do this when you can from any process step, link to and launch an external app that carries out the calculations?
For complex algorithms I don’t see low code working for either of these options, so it’s not so much a question of whether low-code BPM is the best option, but whether it is an option. I say no.
The problem with launching external apps to avoid coding within the mapping environment is that many external apps do not follow the rules of interoperability – i.e. some external apps cannot import and cannot export. If they are able to import/export, you typically have to write a formatter on export from the mapping environment so that the app can read the exported data and you need to write a parser in order to import data from the app. Let’s not forget the data transport and whether the paring of your BPM app with each external app accommodates push or requires pull. Few today are willing to allow direct writes at databases because of security issues so you end up with a database in the middle where publishers push and subscribers pull, each at their own frequency (real-time, fast-batch, batch).
Formatters/parsers are complicated unless you have a generic data exchanger where publishers can use their own data element naming conventions and subscribers can use their own data element naming conventions.
Sorry I missed this debate last month! Lots of very long answers. Could this be a reflection of the newness or threat of the approach in this context?
I was one of those 'kids' in the business unit's shadow IT building useful systems that 'IS' couldn't get to. I say Low-Code solutions are an alternative that should be considered if feasible. (What would motivate someone to omit a viable alternative in their selection?) And, it should be selected if it meets the business project objectives within the constraints better than the others. That, obviously, includes the use case of a requirement for a simple system to help quickly.
Now, does anyone know of a real good low-code solution?
I have absolutely no idea why "low-code" is even being talked about in an age when we've moved beyond zero code and into zero UI. Think about bots and interacting with them over an instant messaging channel. Billions of people across the world already do messaging, so if we are still talking about "low-code" which needs IT - there's something "very wrong" with the industry.
I believe the status quo of the future is truly about zero code and even further - zero UI. We are thinking hard about both, and then the industry will finally embrace new markets like SMB (for whom BPM is not accessible) and new use cases - which do not need an IT or consulting army.
Perhaps the real question should be - why aren't we already talking about BPM with zero UI?