Low-code is on the rise. According to the analyst firms, up to half of medium-to-large enterprises will invest in low-code as a strategic platform for their company in the coming years. For IT leaders, this means that they will soon be evaluating a new, and perhaps unfamiliar, type of technology.
Low-code platforms enable rapid application development through visual and model-driven configuration instead of traditional programming. A typical low-code platform provides a drag-and-drop environment to define and configure data models, user interfaces, business- and application logic, and integrations (APIs). However, when you take a closer look, it soon becomes apparent that not all low-code platforms are made the same.
To help you determine which platform is right for you, we have made a short-list of some dimensions that separate the platforms. The list is not exhaustive but is meant to help you understand the differences and make more well-informed decisions.
Expressiveness
All low-code platforms have some degree of visual, model-driven configuration. However, there are major differences in what can be expressed within the boundaries of the platform.
The foundation for visual, model-driven development of applications is the same as for the model-view-controller (MVC) pattern. You have the data that you want in your application (the ‘model’), the business- and application logic that the application shall provide (the ‘controller’), and the user interfaces presented to end-users (the ‘view’). The differences between platforms become clear when you investigate how they handle these three parts of a basic application.
Most low-code platforms have sophisticated capabilities to provide modern user interfaces (UI) (even though they follow different design expressions). But, when you evaluate the power of their logic and data capabilities, many will show flaws and refer to “custom coding” to express what you need. Why is this?
We use the term “expressiveness” to describe the creative capabilities within the low-code platform’s own development environment – that is: How much can you do within the boundaries of visual, model-driven development without resorting to traditional coding?
Ultimately, the low-code platform should deliver on its promises of what you can build without the need for custom coding.
Security
When you invest in a strategic application development platform for your enterprise, security should be top of mind. Especially since the platform’s security model is (hopefully) an integrated part of the development platform that cannot be tampered with.
The security capabilities of low-code platforms vary, and often depend on the type of low-code platform you look at (code-generating vs. metadata interpreting). The metadata interpreting, codeless platforms are the only ones that can truly ensure that their security mechanisms will be enforced throughout the application.
Testing
Low-code development is different from traditional development, also when it comes to testing. Since most (if not all) the technical building blocks are pre-built by the platform vendor, some of the testing typically performed in programming projects are unnecessary (or impossible) to do by your low-code developers.
When you use a low-code platform, the testing becomes a shared responsibility between your low-code developers (building the applications) and the platform vendor (building the platform).
The default “testing agreement” is that high-level testing of the implementation (e.g. business logic, integrations, user interfaces, etc.) is handled by your low-code developers, whereas the low-level testing of the platform functionality is handled by the platform vendor. This further implies that you must trust that your vendor of choice has the necessary quality assurance to provide a thoroughly tested platform.
However, this configuration of shared responsibility is only true as long as you don’t tamper with generated code (for code-generating platforms) or use custom-code to extend the platform functionality. In such cases, all testing will be your responsibility.
In your evaluation of low-code platforms you should therefore ask: how much testing are we prepared to do by ourselves? If you want to maintain a shared responsibility with the vendor, a metadata-interpreting, codeless platform may be the best choice.
Developer experience
There are two main “user groups” of low-code platforms. The first is the end-users of the applications you build, the second is the low-code developers who will build applications in the platform’s IDE. In addition to the end-user experience, you must take into account who your low-code developers are, as this will help you find the right platform vendors.
Some examples of low-code developers can be found in the table below:
| Professional programmers | Business engineers | Citizen developers | |
| Description | Experienced programmers who enjoy coding | Tech-savvy employees with a business mindset who want to build enterprise applications without programming | Line-of-business employees who need a low-code platform to build smaller applications for themselves or their department |
| What to look for | A low-code platform that allows them to continue coding. | A codeless low-code platform with a high degree of expressiveness | An easy-to-use and easy-to-learn low-code platform (often called “no-code platform”). |
If your goal is to empower every employee to build simple solutions, you should start looking into what is often referred to as “no-code platforms”. However, if you want to empower your organization with a team of business engineers to rapidly develop core, mission-critical applications, you should consider more powerful platforms.
Sustainability and technical debt
Sustainability. The holy grail of low-code.
The most advanced low-code platforms make a clear separation between the application model and the platform it runs on. This allows us to categorize application sustainability into two aspects:
- Is the application model up-to-date with the current (and/or preferred) business practices (Business functionality); and
- Is the platform up-to-date technology wise and free of technical debt?
Technical debt refers to the cost of fixing yesterday’s flawed technology decisions. For instance, an application can be based on an outdated or underperforming underlying technology – making it costly to maintain, upgrade or replace.
Make sure that the low-code vendor takes responsibility for evolving their platform with up-to-date technologies and at the same time replace outdated technologies. This way, your remaining responsibility is to keep the applications up-to-date with your business practices.
Caution:
Some low-code platforms offer the opportunity to enrich your applications with custom code or even modify generated code (for code-generating platforms). If this is the case, make sure that the vendor can promise that such customizations do not drop you off the upgrade path of the platform. If they cannot make such a promise, be aware of the high risks of technical debt.
Integration
A strategic low-code platform is an integrated part of your IT landscape and will communicate with other core systems and applications in your organization. What types of integration capabilities does the vendor provide?
From our experience, there are three main approaches by vendors:
Pre-built connectors: The vendor offers pre-built, integrated connectors to other major, well-known application suites. This is a fast-track to connect to your existing systems and applications (if a connector exists) but be aware of challenges with API versioning.
Rapid, model-driven integration: The vendor offers model-driven tools to rapidly define integrations through well-known technologies (e.g. REST or SOAP). Evaluate how the vendor has implemented these capabilities and look for proof of the effectiveness.
Templates: This is a middle-ground between the previous two, where you can download a “template” for your integration and continue to build on this template. The advantage is a rapid integration without the challenge of API versioning. The challenge is that the template may be suboptimal or hard to understand by your developers.
There is no universal answer to which approach is best, and you must evaluate the platforms based on the needs of your specific organization. If you expect to upgrade or replace several of your core systems in the years to come, a pre-built connector approach is probably not the best for you.
Lock-in
A common fear in organizations considering low-code platforms is “vendor lock-in”. What happens if the vendor goes out of business? Or if you, a few years down the line, find that the platform was not what you expected?
Low-code vendors have different answers to this. Code generating platforms often promise that you can keep the generated code and continue working with it. But how realistic is that? Other platforms come with migration tools, promising the opportunity to migrate to alternative platforms or even third-generation programming languages (3GL).
Such promises should be met with a requirement for proof: Ask the vendor for references to customers who have actually migrated to other platforms or continued to build on the generated source code.
We believe that the key to avoid lock-in is data model migration. The data model should be transparent, and it should be structured based on standard data modelling techniques such as data normalization. Verify that your data will be available in standard databases, and that it is well-structured and easily accessible. With such access to your data, it is possible to migrate to other platforms or tools more easily. When you think about it, the user interfaces and logic would most likely be modified anyway when moving away from any type of business application.
Scaling
You may want to start small, but can you go big? The scalability of the low-code platform should be considered when you evaluate vendors. Some questions to ask are:
- How large data models does the platform support (e.g. how many entities/object classes in one model). This is relevant when you want to build more advanced core applications.
- How does the application logic scale? Can the platform, for instance, handle thousands of transactions being processed rapidly? And does the platform support complex business logic, while still being maintainable in the future?
- How many end-users can be on the platform simultaneously?
The scalability you are looking for often depends on the type of application you want to build. Even so, you should look for evidence on how the platform has been used for larger application scenarios. Ask the vendor to provide reference customers with similar challenges as you have. Look at how the runtime environment is configured – is it based on scalable microservices? Can you easily migrate between on-premises and cloud providers (or the other way)?
Deployment
Scaling also brings us to the next issue: platform deployment. Where are you allowed to run your applications on this platform? Some vendors only offer access to their platform on their own public cloud offering. And, in a lot of cases, this is perfectly fine. But when you want to build integrated, mission critical applications with low-code, you may want to place it closer to your existing infrastructure to have better control of both data storage and processing.
Deployment agnostic platforms allow you to run the platform in the infrastructure of your choice. Whether you want to host the low-code platform on-premises, in a private cloud, in a public cloud, or in the vendor’s own cloud offering – this should be your choice. And you should be allowed to easily migrate between the options.
Conclusion
Evaluating low-code platforms is not an easy task, with hundreds of vendors offering varying approaches to low-code. If you evaluate low-code as a strategic platform for your business, it becomes even more important to understand how the investment will be sustainable over time.
The first step is thus to understand some of the differences between the platforms and consider what is most important for your business.
