The Myth of Low-Code 4: Vendor Lock-in
The Myth of Low-Code 4: Vendor Lock-in
Wiza Teguh
The most common fears that discourage organizations from adopting low-code are inflexibility, vendor lock-in, security, scalability, and career impact. In this article, I will talk about each fear that discourage organizations from adopting low-code, and why they should not be feared.
4.Vendor Lock-in
According to a survey called ‘State of Application Development Survey’ held in 2018, 16% out of 3500 respondents answered “Concerned about Lock-in” as their main reason why they’re not implementing low-code. What does lock-in means? Vendor lock-in makes a customer dependent on a vendor for products and services, and unable to use another vendor without substantial switching costs. It is like you are chained to one vendor and one vendor only.
There are 3 main risks could lead you to a vendor lock-in:
- Dependency on vendor-supplied customization.
It was difficult for customers to achieve self-sufficiency. On any project, they were likely to uncover requirements that the out-of-the-box platform could not handle. Custom capabilities were then shoehorned into the customer’s platform build. In some cases, where such customization was out of alignment with our product evolution, future platform upgrades would entail significant consulting effort. This led not only to vendor lock-in but version freeze as well.
By asking the right questions, you can identify these risks during the purchasing process. Find out how you can build your own REST, SOAP, or other kind of integration using out-of-the-box capabilities. Paying attention to those two things will help you avoid becoming reliant on customizations only your vendor can provide, and thereby reduce the risk of lock-in.
- Dependency on vendor-or consultant-supplied professional services.
At first glance, this may seem like the same issue discussed above. Admittedly, the outcome is the same. However, the causes are entirely different. Instead of product capability gaps leading to vendor lock-in, this is a question of customers being unable to achieve self-sufficiency because of a wide variety of softer issues.
- Dependency on licensed, proprietary vendor technology
All low-code, and indeed no-code, platform vendors promise faster and simpler ways to build applications. However, building is just a fraction of the full software lifecycle. As a customer, we must keep paying for license, to run the application we’ve built.
According to Jason Bloomberg, an industry analyst from Intellyx, there are two different approaches that various low-code platform uses for execution:
- Code-generation platforms: Output executable code that can be installed on a variety of standard infrastructures. OutSystems is one such platform.
- Model-driven execution platforms: host the application in such a way that the platform interprets and executes the model directly at runtime.
If vendor lock-in is your fear, the need to interpret the model at runtime probably gives you the collywobbles. If you stop licensing and paying for the platform, you’ll no longer have access to the proprietary technology that makes your app run. That’s curtains for your applications. Your exit options are perhaps limited to raw data exports and some static documentation.
If you don’t want to be locked in, then your choice must be the code-generation platform. Here are some benefits you can get from code-generation platform:
- The ability to create native mobile apps
- The ability to create apps that work when disconnected from the internet
- The likelihood that apps perform better compared to those that require runtime interpretation
- The ability to continue using deployed apps even if the vendor disappeared
Low-code purpose is to make things simpler. You as a customer, should feel helped by low-code, not to feel as like hostages.
