Why you should have access to your source code, even if you use a Low-Code approach

The Low-Code paradigm aims at providing five significant advantages to your organization:

1. more intensive and efficient collaboration between users, business and IT,
2. a substantially shorter time-to-market,
3. an increased business value for the same total cost of ownership (TCO),
4. reduced demands on IT capacities, and
5. a higher quality of the resulting applications in terms of resilience and effectiveness.

The underlying enablers of Low-Code include visual modelling of business logic, graphical user interfaces to configure and customize applications, extensive reuse of building blocks, integration in and use of the existing IT landscape, and industry standards for authentication and data exchange mechanisms. The list of Low-Code success stories is growing from day to day, and well-known market research companies forecast an impressive potential for Low-Code in the upcoming years.

Despite these promising aspects, a crucial point should not be neglected: do you need to keep access to the source code of your applications?

Reducing vendor lock-in

The first reason you may want to ensure access to your source code is to reduce the risk of vendor lock-in.

The challenge of vendor lock-in is neither new nor exclusive to Low-Code. Instead, potential vendor lock-in is associated with nearly every technical decision, being it for database technology, or a development framework. The big difference in the case of Low-Code is the extent of the impact: while migrating from one database engine to another or from one front-end framework to another is possible with reasonable effort, the situation is different for Low-Code because complete applications, including business logic, are created, stored, and deployed entirely within the Low-Code development platform.

In general, vendor lock-in should be treated like any other IT risk, i.e., one should consider the impact and likelihood of various risk scenarios and decide on an appropriate risk response if they are outside the organization’s risk appetite. Possible scenarios include:

• the vendor may choose to cease supporting the Low-Code platform or to develop the platform in a direction that is no longer suitable for your requirements,
• the business relations with the vendor may no longer suit your needs, or
• the vendor might go bankrupt.

One of the possible risk responses is to mitigate the risk of vendor lock-in by taking measures to maintain access to your source code to facilitate migration to another platform if needed.

Fulfilling regulatory requirements

The second reason why you may want to have access to your source code when using a Low-Code platform are possible regulatory requirements, e.g., regarding transparency and traceability of your applications. Even though a small set of Low-Code platforms is already certified to comply with some of these regulatory requirements, it might be necessary to have insights into the generated code itself.

Approaches to have access to your source code

There are two approaches to get access to your source code when using a Low-Code platform.

The first approach is to get access to the source code generated by the Low-Code platform. Depending on the platform chosen, we can distinguish three levels of source code access, as outline in the following figure:

The level of access to your source code depends on several aspects as well as the goals you want to achieve, for instance:

• the amount of work required to get access to the source code (which can range from easily accessible export functionality to reverse engineering);
• the coverage of the available source code, which can range from the mere code itself to databases, libraries, and configurations;
• whether the source code can be imported into an industry-standard IDE, and whether the source code can be automatically refactored using the built-in capabilities of this chosen IDE;
• the level of comprehensibility of the extracted or generated source code regarding design patterns, naming and code structure;
• the knowledge available in your company regarding the source code and underlying technologies.

The second approach to maintain access to your source code is to avoid Low-Code for business-critical components, i.e., to keep these components in a traditional Pro-Code set-up and components/services. Obviously, in order not to lose the advantages of Low-Code, there must be a healthy balance between the Low-Code and the Pro-Code elements. This balance always needs to be evaluated in the context of the organization’s risk appetite mentioned above: even though Low-Code comes with the risk of the outlined vendor lock-in, there is also a risk when not using Low-Code, even if it would be beneficial for the organization.

The presented aspects and approaches are part of the adesso Low-Code framework that makes the advantages of the Low-Code paradigm accessible and reduces associated risks.