There is a lot of talk about no-code development. What exactly is no-code development? How does it relate to no-code integration and no-code automation? Is it the same as no-code application development? And is that the same as rapid application development?
Also why are there so many even more specific terms like no-code communications or no-code CRM or no-code analytics, etc.? And while we are at it: What is low-code development (or low-code anything else for that matter)?
Let’s break down exactly what all these terms are and try to make sense of this.
No-code development generally means being able to develop some significant software component without writing any code. So far so easy.
No-code integration is the same as above but refers to a software for a process that crosses an interface combining more than one separate system.
If you want a quick view of the kinds of automation and integrated processes that can be done with no-code development, you can find videos here.
What about the other terms?
No-code application development is the same as no-code development. Phew, getting easier already. And as you would expect no-code development can and often does include some no-code integration, i.e. integrating with other systems using a no-code development approach.
Rapid application development is a term that has been around for a good while. To simplify, rapid application development does not promise to involve “no-code”. In fact, generally it is a framework for using a more efficient way to write code for applications.
So far so good. But why are there so many other terms?
So many names and terms
There are two reasons for the plethora of names. One is actually a good reason and so we can expect to see a lot of terms persist.
- The not so good reason: the whole area of no-code development is pretty new and so we have not settled on the terminology yet
- A good reason for all the names: it is unlikely that a no-code approach will be completely general purpose and apply to every domain and every type of software solution. So we can expect to see domain-specific no-code approaches.
Already, we see no-code development systems that are specialised for CRM, others only for data analytics, others only for messaging and communications, others that focus mainly on the integration part. Indeed given the sheer size of some of these domains, e.g. data analytics, there are no-code development platforms for specific sub-domains within them.
No-code X (choose yours) is here to stay
This will continue and it is a good thing. So don’t be surprised to see no-code marketing automation, no-code communications, no-code IoT (and since that is so broad an area, you’ll see no-code GPS device tracking and hundreds of other more precisely defined domains).
Does everyone agree that no-code development is a thing?
Currently among the main analyst organizations like Gartner, Forrester and solution/vendor tracking and comparison sites like G2Crowd, there are categories dedicated to something like no-code development (maybe under a different name sometimes). At the moment disparate solution types are lumped into this one category.
But it really is not clear that this will continue to be the case. For example, already this category “No-code development” has CRM and analytics and integration solutions, which are all very different from each other.
Integration solutions could well deserve their own category – or at least a case can be made for that. Also some of the products now in the single category, like Zoho Creator and Salesforce’s no-code solution, are evolutions of earlier tools for creating CRM custom applications. So won’t these properly land back in the CRM category later?
Well maybe not. Or maybe not in all cases. At present no-code development and no-code integration are actually remixing various capabilities in some interesting ways. So we can expect that some domains will change over the next few years. So it is not yet clear what this will mean for the vendor and solution categories that are recognized as distinct.
However, we can definitely be sure that many well-defined domains are distinct from each other in very meaningful ways that are independent of changes in software development methods. To name just one example, there are very good reasons why CRM and case/ticket management are actually distinct and have remained so: the value proposition, the buyer, the underlying processes modeled, the teams actually using the capability are all rather different in each case.
So I would expect, some no-code development to become additional capabilities within existing categories of solutions. So no-code CRM will be part of CRM capability when the market is more mature. Maybe this will also help tidy up the naming a bit – that would be nice anyway.
Can we make more sense of different no-code development areas now?
At present we can see substantial differences between three different types:
- Where the outcome is essentially a classic database-driven web application
- and others that only focus on integration across systems (generally APIs)
- or, where data is extracted, combined, processed in batches
If you use Salesforce tools, Zoho Creator, kintone, etc. then whatever you create will look like a CRM workflow. In particular, you will create “views” in a user interface for users to interact with and the fields that are filled and the updates saved will be stored in a database. Further views will show at any time what is in parts of that database. No-code development here means dragging fields into views, creating conditional process flows and configuring how the CRM process being modelled will work.
If you use Zapier or ITTT, then the outcome will be that an occurence in one system will cause something to be updated in another system using a request to an API. The no-code part here comes into play because the user just selects what API resource to use and does some config and this will cause the data flow across systems to work.
If you use keboola or VINYL, you will extract data from sources, transform the data, push the data to other tools and/or allow users to analyse the data that is combined and processed. Here the setup of data extraction, transformation and loading of data is done in a user interface that involves no code being written.
These three outcomes and the domains being modelled are very different. So as mentioned I would expect the first and last to split into different categories and not be part of general no-code development. The middle no-code integration approach is interesting precisely because it is joining systems together and so could indeed be a different category. Or at the very least, you might expect, no-code integration to become part of systems integration solutions as a category.
However it does not break down quite so cleanly. The world is as usual quite a colorful and interesting place.
What about all the specific categories?
As soon as no-code development and integration is applied to any significant solution area that involves either its own infrastructure or its own information domain, then we see that we end up with a significantly unique no-code development solution.
For example, if you take any part of the very broad internet of things (IoT) area, then it quickly becomes obvious that a system determining whether there are power surges in high voltage lines is a different domain from helping consumers manage their power use with in home devices and smartphone apps.
Or when you combine no-code integration with messaging and telecommunications, you pretty quickly see that there is a whole massive domain (indeed a set of separated sub-domains) that will each get their own no-code development and no-code integration solution.
So it is very likely that there will continue to be a very large number of solution types that involve no-code development applied to different specializations.
When is a configuration tool not no-code development?
Obviously, there have for many years now been reasonably powerful interfaces that have some configuration that influences how a software solution works. So is my existing CRM a no-code development platform? How do I know no-code development when I see it. When is it just configuration views within a software solution?
The fundamental difference is that you can achieve outcomes that genuinely require the “encoding” of complex processing and decisions. An interface that just provides views for selecting a few options with checkboxes, input fields, etc. does NOT embody no-code development.
Take for example, a system that allows you to create a variable, flag, key, etc. and then evaluate that value, transform it, send it to another system to get a response. This type of processing would in general require writing a coded procedure that has many options and several failure and response types to be dealt with, i.e. it would generally require development.
A more useful example is where a processing object is required. Let’s say you need a technical queuing system that can handle thousands or billions of items (tasks or contact requests or calls or whatever). In a normal SaaS tool, you can add such a thing for the single special purpose that it was prepared for. In a no-code platform, you can usually create such a queue object and do things with it that would normally require a project, with development and QA and deployment, not to mention dev ops engineer to deploy storage and servers and monitoring and everything else to make it operate reliably with high performance.
No-code development makes it possible to create these new entities and standardizes all the things that a developer (and a QA specialist and a dev ops engineer), would normally have to do.
The benefits of no-code development
Since there is no end to the amount of “code” required in the world but a severe shortage of coders with the right skill sets, the immediate need to have some no-code development is pretty clear.
Beyond that there are significant benefits for a business that now gets into no-code development:
- Increase in speed of process adaptation: Operations staff close to the workflow can at any time change it and optimize it.
- Finding, isolating and resolving issues becomes faster: essentially there are less barriers to improvement, since there are more resources capable of doing this work and the toolkits available to them are better.
- The cost of getting to each point of scale will reduce even further than it has up to now. Teams with very little in the way of software development skills will be able to create substantial integrated data flows and processes.
So do we still need developers now?
Yes, we definitely still will need as much quality development skill as the world can produce – and probably even more than that actually. No-code development is bringing the ability to cleverly “encode processes” to far more people. But this will only increase the need for more advanced software to enable the demand for all the processes people dream up.
Also, we are already seeing that there is a whole category of resource who would never code anything but who are getting very skilled at being consumers of complex software interfaces like APIs.
This also brings us to “low-code” development. Almost every no-code development platform allows extensions of capability by doing a little coding. Frequently this means that, an advanced NON-developer user can define for herself how to use a specific API resource or how to extract data incrementally from a database. So we are actually seeing that there is more coding going on and more people who can write the relatively technical configuration files that make all these processes actually work.
[bctt tweet=”If it takes more than 10 seconds to find your no-code development expert, then you are soon going to be in trouble” via=”no”]
In the very near term, the success of a business may depend on how many people you have who master no-code development and integration. How long would it take you now to locate an expert in “no-code development” in your company?