Definition: Low Code
Low Code ==
- a Modeling Language plus
- Domain-Specific Functionality plus
- a Platform and/or
- a Software Creating/Generating Tool
The pointed definition reflects our viewpoint on low code based on the following considerations:
The core idea of low code and its extreme, no code, is to allow developers to develop software efficiently while preventing
developers from writing (much) code.
- The underlying driving forces are:
- reduce the effort necessary to develop software systems,
- allow people, including end-users, to develop systems on their own, even though they are not able to program themselves, and
- when using a reduced set of available program components, the quality of the resulting system may increase.
- So it is all about cost, quality, and sometimes also enabling end-user-development.
To some extent, generative approaches based on explicit models did that already for a while, so low code to some extent bears a good marketing as well as some additional new ideas, discussed below. The Models@Runtime approach, which was discussed intensively for a while, seems to be a successful predecessor for the low code approaches.
Need for Models
- Developers need to be able to communicate their ideas of what the
system should do to the tool and therefore need some kind of language
to express these. Such a language may be
- more explicitly given in form of a domain-specific modeling language, may be
- implicitly embedded in a wizardry tool, only be offered by
- programming API in a normal programming language, or even by a
- configuration language (like yaml, gradle, …).
In each of these cases, an underlying modeling paradigm is present and we can speak of a more or less explicit modeling language and a modeling activity. Let’s call it the low code modeling language (in short LCML).
As a consequence, there is always a LCML involved, even if the language is not defined or even mentioned explicitly.
- If a wizard is available, then a completely new group of users may be attracted to use such a low code approach, because the guidance that a wizard may provide would allow unexperienced, occasionally modelling people to be successful without too detailed training. A smart GUI-based wizard can be of great help to develop low code models. It may offer an intuitive graphics-based UI, present at each point in time the available or needed model elements, provide early feedback on the functionality taken, or (in restricted) cases tell the developer what configurations are available. The LCML model is then constructed interactively and internally and not made explicit to the developers at all.
In difference to traditional modeling of software using UML or SysML, one core novelty is that there is a predefined library or framework of coherent functions that cover a specific domain, such as finance, insurance, tax, accounting, curriculum management, logistics, etc., that are directly included in the LCMLs vocabulary. This makes the use of an LCML for a specific domain rather effective.
As a neat secondary effect, the available function library can also include a persistence component and a set of presentation functions. This means that there is a domain-specific set of GUI components available that can quickly be combined into a useful and comfortable webapp (app or website). Such a GUI then includes domain-specific diagrammatic or graphical presentations e.g. of 3D-situations, time series, etc. It also contains navigation, explanation, and potentially also guidance in business processes, and many more possibilities. These GUI components are are not to be confused with the also GUI-based wizard, because the wizard is used at design time to define how these components show their contents at runtime.
On the downside, a LCML is usually not a fully expressive language. It usually has restrictions of two forms:
- it cannot describe all forms of algorithms, i.e., not turing-complete, but more relevant is often:
- it can only combine certain functionalities and therefore describe certain kinds of systems. If the underlying platform doesn’t provide certain forms of configuration or core functionalities; then the developer cannot develop it.
To complete a software system, there must be an underlying platform that combines many core functionalities, such as persistence, security including rights management and robustness against threats, connections to external systems, monitoring, a presentation frontend, containerization, back up, an administration interface, etc. Nowadays, software stacks are complex.
Of course, the platform also hosts respectively provides the domain-specific functionality.
One might regard such a platform to be like an operating system plus a set of domain libraries.
Often this plattform is itself embedded in a large aplication, such as a business information system, where it borrows the available data structures and domain functionalities and makes them available in the “low code models”.
Interesting distinctions of a low code approach will be, whether local data can be defined, or even the given data structures can be extended by additional attributes/values.
Software Creating Tool
Finally, the platform either also hosts a sophisticated interpreter that allows execution of all models of the LCML or there is an extra tool, i.e. a generator, translating models of the LCML into an executable form of program, typically into a general-purpose programming language.
In both cases, finally, the LCML ends up as a high-level modern programming language irrespective of whether the LCML was defined explicitly or implicitly through a wizard.
An Estimating Outlook
It will be interesting to see how new user groups react, if they can easily do/configure/model the simple things, but after some use detect that they would like to have additiobnal algorithmic features, such as expressional operators, case-distinction, iteration and maybe the possibility to define subroutines/macros. At least the more lively low code approaches will end up in relatively complete “programming languages” with new syntactiv flavours.