NoCode is the next evolutionary step, and not having it is a non-starter. The challenge is, how do create NoCode solutions that *link forward* to the next generation on complexity that our customers require, and don't box them into a vendor or capacity solution?

That, in my opinion, is the heart of the matter.

I agree with Max.
Without truly effective environments that allow business leaders and SMEs to rapidly implement rules and process changes "on the fly" - "as soon as needed" there's no lasting transformation.

Delivery of digital services requires the UI to be intrinsically linked to back office support in a dynamic way to ensure all data correctly collected and processed to deliver on the required outcomes. This includes delivering new data to the relevant UIs for other users. This requires custom build and this is where no code capability is vital for that Adaptive delivery where the UIs are dynamically created for the authorised users with the right data ready for use. The key requirement for Adaptive is the ability to readily implement change; an inevitable requirement at the sharp end of business.

With no code will come transparency as to how the digital service works and understandable by all users. This significantly speeds up build working direct with users and gives confidence that change can be readily supported. This where the BPM discipline will play important role understanding requirements. Nothing should be off the agenda as new ideas emerge and users can become empowered with real-time feed back. Full audit trails who did what when ensure accountability for all.

The challenge which we have experienced has been and still is disbelief and huge vested interests in the existing vendor supply chain which has thrived on complexity resulting in the legacy mess. This mess cannot be ignored so important the no code Digital Business Platform can orchestrate its use and data extraction as required. Do not even think of trying to use existing legacy UIs!

This is going to be a significant change to enterprise software with consequences for many in the supply chain but at last the customer will be the real winner; a true signal of enterprise software at the start of commoditization and maturity.

Happy new year to all!
I truly believe it is important and yes, it has to be done right. And also, no, its not the magic bullet to achieve everything the easy way.
With being done right, I specifically refer to the possibility of accomplishing the whole implementation cycle of putting an improved and automated business process into production, being able to measure and improve upon it. Of course, being aware that a low/no code approach will naturally limiting the user to rather simple processes - which on the other hand make up a large portion of a companies process universe.
"Low coding" only on a flowcharting and simulation level, in my opinion, doesn't manage to shorten the way towards the magical land of Oz and its wonders of digital transformation it beholds

I remember an informal definition of a good programming language - "simple things are simple, difficult things are possible". Thus in your digital business toolkit / platform simple things should be doable without coding and such a platform must simplify coding as well (dreaming about robots and microservices).

Thanks,
AS

Low Code and No Code are going to be fundamental to the digital business transformation... but I am having a feeling of deja vu.

There isn't going to be a single magic bullet to solve every problem this time around either. Business Analysts and their IT friends will have to look at the complexity of what they are tackling before picking a solution... this all sounds so familiar.

Just like the BPM tech market did, the low code market will start to segment out as adoption increases. No code vs Low code certainly appears to be a good starting place. I think no code solutions will be used for the tactical things that just need to get done (that IT doesn't always have time to get to), and the more robust low code platforms will be used to implement, maintain, and change the more sophisticated processes at the core of the digital business transformation.

I think we're putting cart before the horse. Are low-code and no-code important? Well, speed and agility are important, and they're not the same thing. They're important because we are taking as an assumption that the world is changing, and our businesses are changing. Therefore we need to quickly roll new solutions, and adapt the ones we have, to those changes.

Speed + Agility means that our learning cycles are shorter, or potentially shorter, and that our pivot points are increased in terms of how often we can react to what we learn.

If you think Low-code or no-code solutions improve speed and agility, then you probably want them. FYI, Sharepoint and Lotus Notes were low-code solutions. So was Hypercard (no-code?). Let's try to keep it in perspective.

How about we get on the same page here . . . .

No-code or low-code development for what?

1. Does this mean vendor development of a process mapping environment?
2. Does it relate to end users in functional departments using the mapping environment to build workflow steps/data collection forms/ rule sets?
3. Does it relate to vendor development of a compiler to carve up mapped processes/process fragments for role-based performance at the RT platform?
4. Does it relate to vendor development of a run-time workflow/workload management platform capable of hosting instances of plan-side process/process fragments
5. Does it relate to BA/IT development of interfaces to/from run-time workflow/workload management platforms?

Let's turn the question on its head: when is low/no code NOT the right solution? We've got plenty of experience in that department, as we've all been relying on either packaged or hand-coded software for decades.

And where has that gotten us? Virtually every medium-to-large enterprise contains within it another medium-to-large enterprise whose mission appears to be generating mountains of code that rapidly become catacombs. When packaged applications are desired, the edematous software procurement organization lumbers in to ensure the process is as slow, expensive, and contentious as possible. In neither case is the enterprise left with software that can easily be enhanced by SMEs, again and again, in response to changing market and regulatory conditions. One might begin to suspect that digital transformation is substantially driven by these very challenges.

Not every problem is solvable with a single tool—if it were otherwise, what would we all spend our time on this Forum discussing? But our experience with both writing our own code, and buying software off the shelf, has shown those options to be expensive, inflexible, and unresponsive. Low/no code addresses these pain points while providing the integration, analytics, and mobility that are critical to effective digital business applications.

Karl. Here is my response to your questions
1 fact easy to draw a map of processes I was doing it in the 70s with great results! Today that map now can be the no code build environment which then declares throughout to pre built database where application created automatically.
2 relates direct with users any where with workflow inbuilt with rules and forms as required
3 vendor just supplies this "tool" up to customer how used and has complete control. Very suited for Business Analyst skills set working direct with users and thinking BPM. Roles allocation built in to architecture and no compiling in build
4 vendor supplies the tool the business builds the workflow and work load management in allocated task types ...some human some machine and required orchestration.
5 the UIs created in the vendor tool allowing for customer to design as required. The data feed by the vendor in built process engine utilising all workflow and outputs from workloads.

Nothing off the agenda for business in this no code build environment this puts emphasis on the detailed business process requirements with direct input from users. Managers have real-time overview of activity to take any action such as to reallocate tasks if required.

Can we get a throw down at bpm next between jakob (camunda) and scott menter (or someone at bplogix) ? : ) could be fun!

I would like to draw a parallel between software solutions and machine learning (bet you never saw that coming LOL) in terms of fitness for purpose (i.e. solving a variety of business problems, both existing and emerging):

Complete custom / bespoke software - this is an overfitting ML algorithm - you code for the task at hand and whenever you need to change something you need to re-code a lot of it.
Standard, COTS, software - this is an underfitting ML algorithm - you take a highly generalized model that doesn't learn anymore from fresh data (or its learning cadence is way to slow for your needs, think product releases) and try to fit your business reality back into it, or spend a lot to get it to work for your business problems.
Low-code / no-code / RPA - this is again an overfitting ML algorithm - you custom-design a power tool for each of the individual business problems that you have. Whenever the business problems change, you have to re-design the corresponding tools. It's faster to build, faster to deploy, but slower to debug (except for RPA, which has a rather fixed problem domain, so bugs are less frequent).

Hybrid solution - fast code (reuseable, model-driven architecture, with custom coding environment) - this is the optimal balance between standardizing / productizing on previous knowledge and developing new, re-useable artifacts to solve new, emerging business problems. In terms of ML, it trains decently but generalizes excellently.
It is slower than Low-code / no-code for existing problems, but much faster to integrate new knowledge, because it is architected to ingest new business models. So it also matches the great definition of Alex: "simple things are simple, difficult things are possible"

Bogdan raises good point about speed of build. This is where no code changes the game of cost. A custom build with no code including the UIs with correct data layout is estimated at the number of UIs equals the number of man days to build ready for first run. There is so need for a detailed spec as change easy handled A broad outline of the process being addressed with direct contact with users with detailed knowledge gets things moving quickly, this saves a lot of wasted time drawing up detailed spec. This also minimises risk to the business customer in being an other "IT" failure where within days it will be clear if vendor claims are deliverable! To give idea of scale of savings comparing perhaps the most inefficient environment Government where a project to distribute grants cost over £300m using custom coding where as similar exercise using this no code total cost just over £1m over 15+ years including constant change. That's what "disruptive" is...!

Is this no code approach the "silver bullet" that has been the dream or as Bill Gates described as the holy grail of software for so long? Well the bullet maybe ready but firing needs a gun which is context is money and a workable plan to for globalisation. Failure allowing this technology to be "buried" by vested interests is not an option........

Amazing we can have yet another discussion about no-code/low-code and still uncover terrific new insights! Because they are real.

When I hear the word "code" though, "I reach for my revolver". What is this business of code? Who is coding or not coding? And why?

We keep saying there's no free lunch, but the reality of coding as the stack gets built out is that the technology is very complex. A good technology is not had just for the asking. And any technology stack is so much more than code, even if it all starts there. So the savings on "coding" only account for part of overall technology costs. And importantly, the interface between business intentions for transformative software and technologists who can implement is as much of a gap as ever.

So, as the inevitable evolution of software technology to ever more powerful, low-code and no-code products is terrific. But only in the same way that COBOL and FORTRAN were terrific advances on Assembler. Saying low-code/no-code is essential to business transformation is the same thing as saying software is essential to business transformation.

In other words, it's not saying much. Unless . . . one notes two differences with hyper-productive software manufacturing technologies. I say manufacturing because that's the important part. RAD, 4GL's, declarative tools, frameworks, low-code, BPM, even COBOL, are all software technology artefacts which assist in the manufacturing of other useful technology artefacts. The fetishization of the fact that all these things are based on code obscures the difference between software manufacturing software and production business software.

Here are the two distinguishing features of new hyper-productive software manufacturing technology.

First, newer software manufacturing technology presents -- for the first time really -- business concepts as first-class citizens of the technology. BPM is the best example of this, where work and process and artefact manufacturing are all first-class citizens of the technology. Of course business concepts have been instantiated in technology before, as in ERP. But ERP, although minimally customizable, is not "software manufacturing software". It just "is".

The second difference is the expanded role for business analysts, who can be expected to directly use hyper-productive software manufacturing software. And not some of the time or exceptionally. But as a major component of their job descriptions and roles. And such work will not be limited to situational applications, but will be part of core business transformation software. (Such work would be performed along side IT software and architectural specialists on one hand, and business leadership on the other.) The business analyst, like the accountant, is a specialist in deep, even formal, understanding of both general and specific domains. By definition, the job of the business analyst is to build and maintain the technology of enterprise in support of the mission of the enterprise.

This process of moving software construction out of IT to business analyst cadres has not really happened yet. Low-code and no-code makes it possible. It is a viable model for future enterprise, for business analyst careers -- and for the technology vendors which can orient their evangelism in this new direction. As for digital transformation, low-code/no-code is just the software of the future. It's the only way forward.

BPM solutions are commonly associated with low-code / no-code approach in IT management. But what exactly means the word "code" in this widely spread acronym? Programming code used by software engineers is just a technical language utilized to express business logic in a form understandable for IT systems. It is more relevant to speak not about a single language but about a large family of languages with different levels of abstraction or detalization.

As any language, technical language is expected to be clear and laconic in its target domain to allow technical experts write their software logic in a clear and concise way. Is programming language low-code solution for a programmer? It definitely is because it allows writing complex system logic using minimal amount of code. Is the same language low-code solution for a manager? Definitely not because manager looks at the same IT system from the different, higher level.

Therefore, the notion of low-code is not universal but entirely depends from the audience. Low-code solution is such solution, which delivers minimally necessary and sufficient level of details to specific problem. It also explains objective abundance of programming languages. One best language for all situations does not exist because every language best satisfies low-code requirements only for its target domain.

High code systems appear when low level technical code penetrates and impacts higher level business logic. It happens for various reasons but in most cases it is associated with poor decisions on enterprise architecture or inefficient IT management.
BPM as such does not have any relation to amount of code behind business systems. Rather, BPM approach allows to harmonize enterprise architecture in such a way that business processes on each level optimally exist and run in their respective low code environments. Importantly, the nature of this low-code niche is entirely different for each process. However, put together, all these dedicated low-code environments assure drastic decrease of the total code in the enterprise ecosystem by delivery of relevant level of abstraction for each business task.

BPM implies a union of optimal low-code solutions to ensure simple, transparent and manageable enterprise architecture.