Software plays an important role in our society. Our world is driven by software, from the things we do online to the cars we drive. According to Gartner, companies have to have a software strategy to be able to compete. Companies (and to lesser extent, non-profit organizations) have to partake in this transformation to a software-driven world. However, they face three challenges in doing so.
- There is a scarcity of software engineers which only appears to be increasing.
- Next to that, software development is complex and requires a joint effort of software engineers and domain experts. We can see from the increasing popularity of DDD and BizDevOps that companies are aware of this challenge.
- Finally, the process does not stop when the software is developed. Companies do not operate in a vacuum; they are part of a larger world inhabited by customers, suppliers, governments, and competitors. Therefore, companies have to constantly update their software to comply with wishes and demands.
Low-code platforms, a concept first identified in 2014 by Forrester, could be the solution to these challenges. The term low-code emphasizes that these platforms enable the development of software systems with a low effort of coding. They target the citizen developer, professionals without specific software development training, through the introduction of higher-level abstractions such as domain-specific models. An ongoing discussion is if low-code platforms are novel. Are they a rebrand of model-driven development? Or a mixture of model-driven and other techniques? Or do they represent something new? I argue that while from a technology perspective they do not offer something new, the target and focus of low-code platforms is different from model-driven in general.
Given its focus, it seems that low-code platforms are on track solving the first two challenges. Enabling citizen developers to participate in the software development process not only results in fewer trained software developers needed, but also automatically involves the business side in the development of the software. However, we haven’t yet reached utopia yet. Low-code platforms have to live up to certain expectations to be successful. And these expectations introduce new challenges for the software architects designing a low-code platform (LCP).
First of all, LCPs have to support the development of modern, cloud-based applications. Successful software is no longer an application accessible only through a company computer, modern applications are always available from every device. Second, these applications should not only be accessible for humans, we also expect these applications to be open for communication with other systems. This means that other companies can interact with the data and processes inside these applications to create collaborations. Finally, in order to support companies in the long run, low-code platforms need to support the evolution of software applications. Maintaining software should be as easy as creating new software. If LCPs do not embed these design principles, the software that clients will be able to create with them will not satisfy the customer expectations or won’t be able to evolve along the customer needs.
Software architects responsible for the design of low-code platforms face a huge challenge while solving these challenges for their customers. During my PhD research, I’ve taken the software architect as my main point of view while gathering knowledge and creating solutions that support these LCP architects. This article summarizes the most important contributions and suggestions to build the next generation of low-code platforms, the full text of my dissertation Evolution of Low-Code Platforms is available on my website.
In order for LCPs to enable citizen developers to develop increasingly large and complex software systems, they need to incorporate approaches that enable the development of such large systems. Examples of these approaches are architectural patterns such as the microservice architecture style (MSA) and event-driven architectures. Both these patterns provide new ways of modularizing large systems. Abstractions that improve modularization are essential to manage the complexity of increasingly complex and large software systems. The idea behind for instance the MSA style is to develop a number of smaller (and thus less complex) interconnected software systems instead of a large monolithic system. An event-driven architecture assures that different parts of a software system, such as microservices, communicate in an asynchronous manner. This results in a loosely coupled system in which the different microservices can be developed autonomously. Development teams can focus on a smaller part of the system, lowering the complexity of their tasks.
Event sourcing and Command Query Responsibility Segregation (CQRS) are two specific architectural patterns that can be applied in MSA style and event-driven architectures. While these patterns offer a lot of benefits, little knowledge and tooling is available for software architects that need to address software evolution. In my dissertation, we present several techniques for the evolution of event sourced systems that we’ve compiled from interviews with multiple engineers. Software architects can use these techniques to create seamless upgrades within their low-code platforms.
Software applications can no longer be seen as isolated systems, by taking part in software ecosystems they are connected to the outside world. Software ecosystems are used by Software Producing Organizations (SPOs) to increase the value of their software for their customers through collaboration with third parties. These ecosystems are formed around software platforms, which in turn are managed by software platform orchestrators. Software platforms are a set of organizations collaboratively serving a market for software and services.
Application Programming Interfaces (APIs) are indispensable in these software ecosystems. API management is, therefore, a crucial activity for these orchestrators. The third parties that extend the software systems rely on these APIs, making it essential for these APIs to be available and scalable. If LCPs want to support the engineering of software ecosystems they need to offer API management capabilities. Therefore the software architects of LCPs need to plan and develop API management capabilities so that the LCPs can grow in maturity.
Together with my coauthors I’ve presented not only a general maturity model for API management practices, API-m-FAMM, but also surveyed four well-known low-code platforms to assess their current state of support for API management practices. We conclude that while they have several required capabilities, in general they are not yet focused on supporting the citizen developer in developing APIs and growing software ecosystems. In the coming years, low-code platforms need to evolve from application-building platforms into platform-building platforms.Low-code platforms need to evolve from application-building platforms into platform-building platforms. Click To Tweet
Change Impact Analysis
The most difficult challenge for software architects developing low-code platforms is the analysis of change impact. Changes that are made, by both software engineers as well as the citizen developers, within a low-code platform have an impact on other parts of the platform, including the other software artifacts in the ecosystem. While some of the changes are innocent, other changes require data conversion. The analysis of the impact is difficult because of the higher-level abstractions offered by low-code platforms, but for companies using low-code platforms this analysis is essential in maintaining control over their applications and the LCP should support them in the determination of the affected components and their (semi)automatic evolution.
In our final research, we’ve proposed The Impact Analysis for Low-Code Development Platforms framework. This framework supports the process of software evolution. Software architects can use it in the design of their low-code platform, making sure that companies stay in control of their systems.
The work that I’ve started in my dissertation is not finished. More knowledge, guidelines, and tools should become available for software architects to support the design of low-code platforms. This will make their job easier, and allow them to focus on the discriminating features of their platform: the type of applications and platforms that can be created.
Michiel Overeem is a Lead Software Architect at AFAS Software (a dutch-based ERP company) where he leads a team responsible for the low-code platform beneath the ERP cloud platform. He received his PhD in 2022 with a dissertation on evolution of low-code platforms. His main interests are in low-code platforms, event sourced systems, and the microservice architecture style.
Michiel, great job.
This work makes us think about the development and maintenance of environments from low-code to low-code.
Evolution and maintenance are far too often overlooked and see this work highly relevant. I also see that companies having built their own low-code platforms that they also use (one case described here: https://modeling-languages.com/comparing-the-effort-of-developing-enterprise-applications-with-programming-and-with-domain-specific-modeling/ ) are better equipped to manage the evolution than those using 3rd party tools.
> Low-code platforms need to evolve from application-building platforms into platform-building platforms.
Indeed, I’ve seen this trend also in my day-to-day practice. That’s what we do at PayFit (https://payfit.com/) and I know that’s where Generative Objects (https://www.generativeobjects.com/) aims toward as well