We call it Lean BPM, but you’ll hear No Code, Zero Code, Low Code, while from Gartner, it is High Productivity Application Platform-as-a-Service, and Forrester splits the whole No-Code/Low-Code niche into Low-Code Development and Mobile Low-Code Development.
Confused yet?
Adding even further to the confusion is just who Low Code/Lean BPM/No Code platforms are actually for is not really clear.
The obvious distinction is between those app development solutions which require no coding ability and those which do. I like to think that the distinction ought to be between the various target users of the platforms, and whether they are the initiators of innovation or not.
I am a Citizen Developer, someone with little to no coding skills whatsoever, but I understand the processes I work with, understand how to look for and test potential improvements, and can build new ones from scratch to suit our needs. This is where the Lean BPM and No Code solutions live: serving the needs of non-developers like me who are looking to quickly and cheaply build effective business applications, without needing to know how to code.
Then there are Low-Code solutions which do require coding ability in order to make them work. These are targeted at developers and coders looking to speed up their creation of business apps without having to hand code (or at least not so much).
Why do I make this distinction?
My reasoning is because I believe process innovation within the business is initiated by Citizen Developers not by IT departments or coders.
Citizen Developers live closest to the work and the processes which govern them (including shadow processes). They are the business analysts, stakeholders, team leads, supervisors, project managers – the people you work with if you are not in the IT department. Going to the Gemba is a Lean principle, however this goes beyond working through and collaborating with those “doing the work” to figure out how to improve. I am referring more to who actually gets to spark of the idea that making a change can result in improvement.
The pragmatic transformation challenge is that while innovation starts in the business, can change be delivered quickly and cheaply by IT?
The answer to that is often no, and there are good reasons why this is so which we will not be covering here, but fundamentally it is because innovation originates with the people working with, contributing to, or affected by the processes involved.
In this regard, imagine just how disruptive providing every enterprise worker with the power to modify and create processes on the fly truly is.
This is the disruption Lean BPM is delivering into the market, but there are other forces at work, and some are positive and some are not.
Positive Disruption Influences
I see two major forces creating and augmenting further Low-Code/No-Code disruption:
Software-Defined Everything (SDX)
SDX platforms have enjoyed substantive improvements to their model-driven approach, and we are seeing exceptionally high-levels of power and usability with them. We are seeing a piecemeal approach to development of SDX capabilities, and this is also spread across a wide range of products, so we feel the impact rather than see it.
The distinction between software tools is disappearing, and as usability increases, so the distinction between Citizen developers and professional coders will become less important.
Artificial Intelligence (AI)
I believe that AI will be able to resolve the thorny issues revolving around structured and semi-structured data sources and how these can be integrated. I also see AI providing a workflow autocomplete for business app creators, providing Citizen and professional developers with the ability to build complex logic into processes which are then directly published into a live, operational state.
Moving beyond this, I cannot guess how far-reaching AI will get when we look at handling exceptions and edge-cases, but I suspect the results will be to reduce reliance upon professional developers even further.
Barriers to Lean BPM Disruption
If we accept Lean BPM/No-Code is so innovative/disruptive, then the obvious question is why are we not seeing more innovation and disruption in the No-Code market?
I feel the answer is that we are reaching a level where more disruption is too disruptive, even to the point where it is threatening.
Let’s consider who is affected by Lean BPM disruption in a world where the mantra is that it takes 6 months, a 7-figure budget and a dozen specialists to create an enterprise application.
Consultants and Big System Integrators
Consultants run on billing out their developers, and Lean BPM threatens their business model.
You simply do not need an army of junior developers at $150 an hour and this is especially applicable to the big system integrators.
IT Department Pushback (and Opportunity)
Lean BPM/No-Code is a scary thing for IT people for two reasons: credibility and fear of job loss.
Credibility is affected when enterprise software development ‘requires’ “big budget, big teams, and lots of time.”
Lean BPM/No-Code are so disruptive that my job as a hand coder is threatened.
Enterprise Architects have long been looking to provide a flexible, agile, and usable infrastructure to allow the business to get to the power technology delivers. Lean BPM also provides a secure environment to act as a play pen for the business to go wild in, but the supervisors/support come from the business not IT. IT support burden is eliminated or greatly reduced because they only need to ensure the play pen confines are secure, leaving admin functions such as password resets, workflow and form creation to the business itself.
Enterprise DevOps
For many of my coding friends, they would rather be allowed to code than get a corner office, salary hike, and management responsibility (I am serious, a good friend of mine and a close work collaborator would rather he had a basement all to himself than have to deal with other people).
And therein is the issue: Lean BPM and No-Code are maturing to such a point that there is less and less need for any hand coding at all, and this is making hand coding (and coding jobs) much less relevant.
Lean BPM does not care about making your IT operation leaner, faster, more effective: Lean BPM only cares about delivering process and transformation power into the hands of all of your people so you can become whatever your customers want you to be at any time.
Digital Transformation Disrupted?
Digital Transformation is itself being disrupted, as the need for hand coding becomes increasingly irrelevant (but not ultimately dispensed with).
Enterprise DevOps has seen coders hired by the bus load because their skills are seen as a strategic prerequisite.
Lean BPM, No-Code, Low-Code solutions by whatever name or classification you give them all reduce or eliminate the need for hand coding in the creation of business apps.
This reduction in reliance on hand coding will only accelerate as AI and other transformation drivers kick into play.