In the enterprise software development market, a lot of attention is currently being paid to low-code and no-code platforms. To a lesser extent, there is also talk of model-driven. Typically, in promoting these types of platforms, emphasis is placed on having to code (typing lines of code) less or not at all and a graphical editor supposedly being the better alternative. But you can put a graphic skin around everything. The unanswered question is whether the underlying model of software development is better than before. I do not think so.
What do those terms in the title actually say? Unfortunately, not that much. As noted, the only thing you can assume is that you have to ‘code’ less and that a graphical user interface is offered as an alternative, in which you can create and update your software. Some investigating shows that they also contain all the underlying concepts of ‘modern’ application development: a data model, the ability to perform all kinds of functions and procedures and an independently configurable graphical user interface for the application to be delivered. Three separate models that describe three aspects. It fits seamlessly with the 3-layer model in the application development of the past 30 years.
In short: each of these platforms has created a graphical editor to support software development. The basis underneath is that of the most common form of software development of the past 30 years, if not longer: the three-layer architecture. And graphical editors for this kind of software have been created before.
What is now causing its popularity is of course a good question. I myself think that the fact that it is providing an integrated development environment, with a standard choice for the application structure. In which the final delivery of the application is also considerably simplified. As a result, less work and background knowledge is required. Graphical editors for data models, processes and graphical user interfaces have been available for some time, but integrating and combining these with application rollout tooling works better of course. And finally, there are a few environmental factors, such as a tense market for software developers and the fact that it is known in the market that the alternative of engaging large quantities of low-paid developers abroad is also not yielding good results.
The keyword in the description above: simplification. Fewer choices have to be made about structure, technology and delivery. Plus the fact that a graphical editor (instead of code) makes it easier to discover what you can do, which makes it easier for a new software developer to get started with. Just like the GUI from Apple and Windows could also show many new users the capabilities of computers. This ensures that the so-called ‘citizen developer’ can create an application himself and can usually roll it out immediately.
But … you can already feel it coming: there are limitations to these platforms. Underlying, not much has changed; a few choices have already been made and a graphical layer has been created over it. The most important limitation: this does not help you if you really want to create complex applications. Some of the choices that a low-code platform has already made for you, will in that case prove to be untenable and a graphical layer for creating a complex application suddenly becomes a lot of work to use. Just think of dragging together hundreds, if not thousands, of screens. You would want to generate something like that.
We can do better. With Alan (https://alan-platform.com) we offer an alternative development model under the hood, which we can best call domain-driven: it allows you to create one integrated model of the domain to be supported, which contains all the important aspects, and no more than that . With five major benefits:
- It makes lightning-fast development and maintenance possible, both for new and mature products and for simple as well as complex applications.
- There is always a graphic shell available that supports full functionality.
- Links with other systems can be fully described and easily linked.
- Technical testing is not necessary, because the domain model is checked as a single integrated whole and can therefore no longer contain any technical errors. This is normally the bulk of the test work. What remains is functional testing.
- New versions of the platform, new standard techniques (voice instead of gui) are always easy to roll out, because the modeling language is completely independent of the underlying technology and structure.
There is much more to tell about it and I will gladly do so in the coming period. This technology has been 20 years in the making and in recent years this development has gained momentum, making it more widely applicable. It’s time to do so.