Since low-code became the new buzzword, I wondered whether there was anything really different in the low-code movement compared to what we used to call model-driven engineering/development. The 1st Low-code workshop (part of the Models 2020 conference) was the perfect excuse to take some time to reflect and write down my thoughts on this topic.
This is the current “raw” version of the paper I wrote for the workshop. The paper was accepted and I need to prepare in the next days a new version of the text that takes into account the feedback from the reviewers. The goal of this post is to try to collect additional feedback from You that I can also integrate into the new version of the paper or that I can use for the presentation of this work at the workshop. I do believe this (the positioning of low-code in the model-driven world) is a discussion we need to have as a community. Even if we don’t reach any consensus.
DISCLAIMERS: 1 – This is a short position paper and should be read and interpreted as such. 2 – It is probably controversial. If you feel offended when reading it, I did a good job. I think the point of position papers is making strong and bold statements that help to start a discussion. 3 – It is difficult to “scientifically” compare two terms when one of them “low-code” is not scientifically defined but needs to be inferred from studying the set of tools that call themselves as such.
Having said this, keep reading for my thoughts regarding the positioning of the low-code movement within the field of model-driven engineering. In particular I try to give some partial answers to the questions
- Is there something fundamentally new behind the low-code movement?
- How does it relate to other concepts like Model-Driven Engineering or Model-Driven development?
- what are the implications for researchers in the modeling community?.
Low-code application platforms accelerate app delivery by dramatically reducing the amount of hand-coding required (definition is taken from this Forrester report , attributed as the origin of the term low-code). This is clearly not the first time the software engineering community attempts to reduce manual coding by combining visual development techniques (what we would call “models”) and code generation. In fact, as Grady Booch says, the entire history of software engineering is about raising the level of abstraction.Low-code is the latest attempt to reduce the amount of manual coding required to develop a software application. This is the same goal we have been chasing since the beginning of software engineering Click To Tweet
Low-code can be traced back to model-driven engineering. But model-driven engineering itself can be traced back to CASE (Computer-Aided Software Engineering) tools. Already in 1991, in the 1st edition of the well-known CAiSE conference, we could find papers stating concepts like: “Given the final model, the complete computerized information system can be automatically generated” or “we arrive at a specification from which executable code can be automatically generated”.
At the same time, the impact of low-code in the business world is also evident nowadays, including some bold projections but also actual factual numbers regarding recent investments in low-code tools, the commercial success of some of them or just the fact that all the largest software companies are making sure they have some kind of offering in this domain.
Low-Code vs Model-Driven vs Model-Based vs No-code
We do not have universal definitions for all the MD* concepts. My own (informal) definitions are the following:
- Model-driven engineering (MDE): any software engineering process where models have a fundamental role and drive the engineering tasks.
- Model-driven development (MDD): MDE applied to forward engineering, i.e. model-driven for software development.
- MDA is the OMG’s particular vision of MDD and thus relies on the use of OMG standards.
- Model-based engineering/development: Softer version of the previous respective concepts. In a MBE process, software models play an important role although they are not neces-sarily the key artifacts of the engineering/development (i.e. they do NOT “drive” the process).
An example of the MBE vs MDE difference would be a development process where, in the analysis phase, designers specify the platform-independent models of the system but then these models are directly handed out to the programmers to manually write the code (no automatic code-generation involved and no explicit definition of any platform-specific model). In this process, models still play an important role but are not the basis of the development process.
Based on the above definitions, I see low-code as a synonym of model-driven development. If anything, we could see low-code as a more restrictive view of MDD where we target only a concrete type of software applications: data-intensive web/mobile apps.
Note that the term no-code is sometimes used as a slight variation of low-code. In fact, we can often see tools defining themselves as no-code/low-code tools. Nevertheless, to me, the key characteristic of a no-code approach is that app designers should write zero code to create and deploy the application. This limits a lot what you can actually do with no-code tools. We are basically looking at template-based frameworks or creation of workflows mixing predefined connectors to external applications where the designers, at most, decide when and how certain actions should be triggered
Another way to compare these different paradigms is by looking at how much manual code you are expected to write. In MBE, you may have to write all the code. Instead, in MDD and low-code, most of the code should be generated but you still may need to customize and complete the generated code (most MDD tools include some kind of black box modeling primitive where you can write any custom code that should be added during the generation process). In no-code you should write zero code.
Obviously, more research is needed to evaluate the low-code tools in the market and better characterize them in less coarse-grained categories than those presented here. In fact, right now, there is basically no research around the low-code movement (a quick search only reveals some papers about tools that classify themselves as low-code but not about low-code itself as the object of study), something that I am sure this workshop will start to change.
Low-code is trending
As shown in the Figure 1, interest in low-code is as its peak, even if, as depicted in Figure 2, this peak is much smaller than the attention model-driven was getting on its prime.
Google Trends graphic showing the search interest for the low-code term
But, if, technically speaking, low-code does not really bring anything new to the table, why this popularity?.
- First of all, I think low-code conveys a much clearer message than model-driven/model-based. Model is a much ambiguous word and therefore the concept of model-driven is more difficult to explain than low-code (everybody has a clear view of what code is, and low-code becomes self-explanatory).
- Secondly, we know modeling scares developers away. Instead, low-code sounds more familiar. It is the same they already do (coding) but less of it.
- Moreover, the application scenarios for low-code are also clearer. Instead of selling that you can do anything with MDD (which ends up generating mistrust), low-code looks more credible by targeting specific types of applications, those that are most needed in industry.
- Low-code is also typically a one-shot modeling approach, meaning that you have models and the generated code, no complex chains of refinement, no model transformations, no nothing.
- And on average, low-code tools are nicer than our traditional heavy modeling tools. For instance, most are web-based and do not depend on EMF.
All in all, I haven’t seen any notation, concept, model type or generation technique in a low-code tool that I couldn’t find similarly in the model-driven world. But for sure, these same techniques are presented, configured, adapted and “sold” differently, which in the end makes a big difference in how low-code novelty and usefulness are perceived. And the success of a MDE project often depends more on social and managerial aspects than on purely technical ones . This does not come for free (lack of interoperability, vendor lock-in, expensive business models,..) but this does not seem to deter the community at the moment.
Low-code as an opportunity
As pointed out before, I do not believe there is any fundamental technical difference between MDD and the low-code trend. In fact, we could take almost any of the open challenges in model-driven engineering  and just change “model-driven” by “low-code” to get, for free, a research roadmap for low-code development (e.g. we need better ways to integrate AI in low-code tools or we should strive as a community to build a shared repository of low-code examples for future research).
But I do not see this as being negative. More the opposite. Clearly, low-code is attracting lots of attention, including from people that were never part of the modeling world. In this sense, low-code is lowering the barrier to enter the modeling technical space. As such, to me, low-code is a huge opportunity to bring modeling (and our modeling expertise) to new domains and communities. If we can get more funding/exposure/users/feedback by rebranding ourselves as low-code experts, I am all for it. This is exactly the approach that many well-known so-called low-code companies have taken (feel free to play with the Internet Wayback Machine and see how their websites mutate from visual modeling, agile development, CASE tools and similar keywords to low-code in the last years). Let’s also take this opportunity to better understand the factors that make modeling-like techniques resonate in the broad software community and learn from it.Low-code is a huge opportunity to bring modeling (and our modeling expertise) to new domains and communities Click To Tweet
And while we do that, let’s keep an eye on the market trends to come. Some low-code vendors are shifting (yet again) their marketing efforts. It may not be long before we start chanting: Low-code is dead, long live multi-experience development.
- Antonio Bucchiarone, Jordi Cabot, Richard F. Paige, and Alfonso Pierantonio. Grand challenges in model-driven engineering: an analysis of the state of the research. Software and Systems Modeling 19, 1 (2020), 5–13. https://doi.org/10. 1007/s10270-019-00773-6
- Jon Atle Gulla, Odd Ivar Lindland, and Geir Willumsen. 1991. PPP: A Integrated CASE Environment. In Advanced Information Systems Engineering, CAiSE’91, Trondheim, Norway, May 13-15, 1991, Proceedings (Lecture Notes in Computer Science, Vol. 498). Springer, 194–221. https://doi.org/10.1007/3-540-54059-8_86
- John Edward Hutchinson, Jon Whittle, and Mark Rouncefield. 2014. Model-driven engineering practices in industry: Social, organizational and managerial factors that lead to success or failure. Sci. Comput. Program. 89 (2014), 144–161. https: //doi.org/10.1016/j.scico.2013.03.017
- John Krogstie, Peter McBrien, Richard Owens, and Anne Helga Seltveit. 1991. Information Systems Development Using a Combination of Process and Rule Based Approaches. In Advanced Information Systems Engineering, CAiSE’91, Trondheim, Norway, May 13-15, 1991, Proceedings (Lecture Notes in Computer Science, Vol. 498). Springer, 319–335. https://doi.org/10.1007/3-540-54059-8_92
- Clay Richardson and John R Rymer. 2014. New Development Platforms Emerge For Customer-Facing Applications. Forrester: Cambridge, MA, USA (2014).