No-code (the ability to create new software applications without writing a single line of code) and its less extreme version, low-code, are trendy. All big companies are buying into it.
We’ve discussed before that no code and low-code ideas are not new. They are just the latest reincarnation of modeling and code-generation techniques. Same as the difference between model-driven and model-based software development, we could see no-code as belonging to the family of model-driven approaches while low-code could be somehow more aligned to model-based ones (depending on how “low” is the code).
As such, to me, no code means it’s all modeling. As Antoni Olivé used to say (make sure you read his excellent book on Conceptual Modeling):
Modeling a software system is not an option. The only decision is whether to make those models explicit – Antoni Olivé
Depending on the no-code tool, models will be more or less explicit. Some no-code tools offer a kind of (limited) graphical modeling / visual programming environment. Others follow a more template-based approach where the user role is mostly configuring the template. In the former, the models are explicit, in the latter, they are implicit and embedded in the template itself. This is the typical trade-off: a template-based approach is easier to learn and get started with but it is restricted to a very limited range of applications.
Unfortunately, marketing around (especially) no-code tools is not that clear on their limitations. I feel we are repeating the same mistake we did a long time ago with UML and we are going all over the hype cycle again. We must be close to the Peak of Inflated Expectations by now. I’m afraid the no-code bubble will burst at some point.
The good news is that regardless of the term we use, every time the software community aims to improve productivity, reduce costs, simplify the development, democratize it,… it always ends up pointing to the same solution: higher abstraction and modeling. Call it no-code if you want, but you and I know the truth: it’s all about modeling!.
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
The modeling community should analyze the low-code phenomenon with a more open attitude and should not be afraid of it. On the contrary, we can still learn a lot.
Saying that, after all, it is nothing new, that it is all about modeling is very conservative, and – as computer scientists – dangerous because we might miss excellent opportunities to understand where current modeling methods and platforms fall short.
According to my understanding (please note that there is a diversity of platforms that are difficult to capture with a universal definition), some distinctive aspects of low-code development platforms are:
– reduced accidental complexity (UIX + cloud-based): most of the platforms have an excellent UIX and do not require any installation because are cloud-based (in contrast think about how many Eclipse instances are currently installed on your machine just to overcome the problem of compatible versions)
– the notations are component-based rather than domain specific: functionalities are defined on generic types that can be actualized with concrete types (the most similar things in MDE are facets, but it is much more than just interface and actualization mechanisms)
– the notation has a notion of data flow (that resembles fluent APIs) that naturally induces a control-flow
– etc
My two cents!
Alfonso Pierantonio
I could agree that some low-code platforms are new and, as such, they may use new stacks or have innovative ways to face software development. Others, well, they just changed their name (from model-driven to low-code) as part of a marketing strategy.
The other points you make (on the notation side of things) is indeed interesting. I believe we need some kind of survey of no-code tools to better understand what are their innovations behind them
I disagree 🙂 they might use model-driven technologies under the hood, however it is not IMHO model-driven. It is surely related and it worths analysing the details.
Hi Alfonso,
I think, your definition of the term “model” differs from at least mine. Could you please provide me your definition of these terms.
/Carsten
Hi Carsten,
probably it does not differ too much from yours, ie any mean for leveraging, representing, and managing abstraction may be considered a model.
What I meant above is that many low-code platform notations have two basic concepts (in modeling terms) or metaclasses: edges (for the flow) and components (for data sources and destination, and data transformations – simplifying a bit). You might look at it as DSL but actually these are sort of general-purpose glueing languages with a very well designed component connector mechanisms that come with a strong UI counterpart. From the end-used perspective, these are models but saying that these are nothing else than modeling means neglecting the effort for drastically reducing the accidental complexity.
In my opinion, the actual challenge is the scalability of such low-code applications, they are mainly made for personal use.
Hi Alfonso,
“… many low-code platform notations have two basic concepts (in modeling terms) or metaclasses: edges (for the flow) and components (for data sources destination) …”
maps to OMG MOF
“… and data transformations …”
maps to OMG MOFM2T, ATL, XPand, …
I consider this a MDSE mechanism.
/Carsten
Hi Carsten,
yes, it is but it does not justify that “low-code is all about modeling”. There is more, eg. there is no way of generating a low-code platform with current modeling frameworks (eg EMF). Understanding why might represent to first step for filling the gap.
Alf
Hi Alfonso,
“There is more, eg. there is no way of generating a low-code platform with current modeling frameworks (eg EMF).”
!!! HATRICK !!!
That is the third time I implemented something, to get told later it is impossible.
/Carsten
Hi Alfonso,
a second reply to
“There is more, eg. there is no way of generating a low-code platform with current modeling frameworks (eg EMF).”
BonitaSoft BPM also is a low-code platform based on the Eclipse Modeling Framework (EMF) [https://www.bonitasoft.com/low-code-application-development-platform].
I really do not understand your point.
/Carsten
Saying that “[low-code] it is all about modeling” is simply false IMO. It does not mean that it is not related to modeling. For instance:
1. is a low-code application defined with a model? yes, it is
2. is such model domain-specific? not in the usual acceptation of the term (the modelling notation is “limited” to flow + component + generics)
3. how code generation/intereptation is achieved? difficult to say, it might be that under the hood model transformation techniques are used but it is diffucult to say
4. is a low-code editor generated with a meta- editor (eg Sirius)? no
5. are low-code platforms generally featuring advanced aspects, including cloud-based, ML/AI, that are not present in generic modeling platforms? yes, there are (although there exists attempts in adopting AI in modeling, however no systematic features are present in things like EMF).
The fact that Bonita qualifies itself as a low-code platform does not say much. Is there a definition of low-code platform? the only one I know is the one gave by Gartner (it lists 144 platforms) and Bonita is not included. Because if bonita is a low-code platform, so is also Simulink and any code-generation capable platform.
Last Alf
In my opinion there is a huge grey zone between modeling and programming. In general I presume modeling is on higher level abstraction than programming. Nevertheless I personally am unable to state where modeling ends and programming starts.
/Carsten
Agreed. I don’t see the need to try to define a clear-cut distinction between them. I’ll be happy enough if everybody understands the benefits of raising the level of abstraction (and its challenges, of course)
Top-brand-no-code-products take your understanding of the problem to solve and helps you codify it into their own proprietary format – albeit with visual tools – they “trick” their users into thinking they have not coded.
I argue we should declare problems and have machines that fulfill that declaration.
Expanded argumentation: https://blog.mdriven.net/is-mdriven-really-no-code/