Science-based benefits (and limitations) of low-code platforms

The use of modeling practices brings many benefits but the rocketing popularity of low-code platforms has attracted a good number of claims about the pros and cons of this particular style of model-driven engineering.

In this post, I report on the great analysis work done by Jelle Systra in the “Quantifying the effectiveness of low-code development platforms in the Dutch public sector” Thesis Master ICT in Business, LIACS, Leiden University, to report on the benefits and limitations of low-code according to the scientific literature and his attempts to validate (or double-check) the empirical results from these published works via a set of interviews with practitioners.

Scientific evaluation of low-code platforms

According to the published literature, low-code development platforms (LCDPs) bring the following benefits to the development process:

• Less hand-coding, faster (5-10x) development, reduction of development time, 50-70% faster application development life-cycle.
• Easy and rapid deployment due to cloud deployment with little effort.
• Cost reduction, as less development, less maintenance, and easier deployment can turn into a reduction in starting and long-term costs.
• Complexity reduction, as development is simplified by (re)using prebuilt components
• Easier maintenance, as there is less high-code. Maintenance can be performed by citizen developers, but only if the system’s customizations are well designed
  and structured. However, with an increased project size it can become too complex for citizen developers.
• Inclusion of business profiles, as the simpler and more intuitive way of development with LCDPs allows business users to be directly involved in the development of
  apps. Participation of nontechnical employees (citizen developers) at an earlier stage in the project.
• Fast prototyping. A fast minimum viable product ensures quick validation of ideas and customer requirements before committing too many resources. Minimization of unstable or inconsistent requirements as fast prototyping allows the team to quickly find conflicting requirements while their impact is still limited.
• Accelerate digital transformation, as LCDPs give new tools to facilitate and automate new application development to promote transformation.
• Increased responsiveness to the business and enabling citizen developers to improve internal processes. The developers of LCDPs require a different skillset as they need to be closer to the business and more communicative. The development team can skip technical details and focus on the business rules implementation.
• Reduce dependency on hard-to-hire technical skills. LCDPs are easier to learn than traditional hand-coded solutions.
• Escape legacy debt, by replacing legacy systems or building layers over legacy systems organizations can `escape’ the in flexibility caused by older IT systems.
• Protect against technology churn, as LCDP take care of certain aspects of application development and deployment which are prone to getting outdated.
• Portability of the developed application, as most LCDP can deploy applications as both mobile and desktop versions or as a web application which is usable on both.
• Interoperability, as most LCDP allow for many connectors/API’s to be made increasing the ease at which information can be exchanged between information systems.
• Integrated agile way of working, some LCDP vendors have integrated agile methodologies in their platform. This could result into more communication between stakeholders, faster development cycles, and more developed applications using the LCDP.
• Easy life-cycle management, due to deployment, monitoring, and management functions being built into most LCDP.
• No unit-tests, as smaller applications can go straight to production.
• Process automation, as small automation features can be easily created, e.g., email confirmation, record creation/updating (might be Salesforce specific).
• Scalability, as most LCDPs are run in the cloud ready to allocate more resources to specific applications if demanded.
• Continuous integration, as most LCDPs are run in the cloud they can relieve developers of most back-end work needed to get applications running after new updates.
• Lower fixed costs, as most LCDPs offer usage-based subscriptions the initial costs costs for starting an application are lower, especially for smaller organizations.

But the same sources also point out a list of limitations of LCDPs. Note that many of these are linked to the maturity and limited features of the tools which is something likely to improve in the near future. Current limitations are:

• Scalability, as current platforms are not ready for large-scale projects or mission critical enterprise applications (even if some argue otherwise).
• Fragmentation, as LCDPs can become an isolated part of the enterprise portfolio adding cost and complexity. Each LCDP presents their own programming language, resulting in little cross LCDP cooperation and difficulties in reusing pre low-code programs.
• Vendor lock-in, as it is easy to become dependent on LCDP and there is no easy way to transition out of it without high costs. Once locked-in, there is little bargaining power for a customer to avoid price increases. Some LCDPs produce generated code or other ways to export the models to give customers some tools against vendor lock-in.
• Issues in real-time data processing, as LCDP need to be able to handle all sorts of situations they are generally inefficient and therefore struggle to handle real-time data processing needed for e.g. IoT devices.
• Limiting creativity and exibility, as solutions are limited by the capabilities of the selected LCDPs and its domain-specific language.
• Lack of a general testing framework, resulting in limited testing capabilities as some LCDPs are reliant on third-party testing tools with limited automation.
• Testing can be too difficult for citizen developers. This is a great limitation of the potential as citizen developers are the system functionality and requirement expert.
• Lack of evidence of citizen developers in action found in research.

You can find the exact papers backing up each claim in the full thesis manuscript.

What practitioners say about low-code

The validity of each of the previous claims depends on the quality of the scientific paper/s backing them. This is an exercise left to the reader.

Nevertheless, in Jelle’s thesis he complemented the literature assessment with that of six senior experts at Capgemini (two enterprise architects, two solution architects and two business analysts/consultant). All of them with several years of experience. Half of them had participated in low-code projects before. They were asked to go through the claims above and choose those that: 1- They agreed with and 2- Were regarded as benefits that could be directly attributed to the use of low-code. These are the benefits (and the wording) they chose.

1. End-product portability
2. Easy deployment
3. Continuous integration
4. Platform-as-a-Service
5. Technical interoperability
6. Visual interface
7. Real-time editing
8. Reusable components
9. Ease-of-mastery
10. Less hand-coding
11. Easier maintenance
12. Fast prototyping
13. Agile-supportive
14. Facilitating business-IT alignment

 

What is your take?

And you? What do you think about the claims listed herein? Would you add/remove some? What has been your experience with low-code so far?