Businesses need to make adjustments regularly. Sometimes minor, like adding an attribute or moving a button. And sometimes, changes could be more significant, requiring the development of something fundamentally new. In the traditional code-first paradigm, the developer is responsible for developing the functionality and all the edits. Everyone loses in this.
Developers — because as the project grows, they are more involved in minor improvements and less and less in reused code. Business — because I have to wait for change. We are aware of cases when developers are busy with minor improvements, and in the meantime, the waiting list of the company accumulates 50 or more projects.
In the low-code concept, the developer does not create the final value but the constructor for its assembly. Collecting or reconfiguring the value in the constructor is faster and easier: not only developers can do this, but also business analysts or end users with development skills (what Gartner calls “citizen developers”). Moreover, for some tasks, these constructors are already available. For example, it makes no sense to create an integration constructor or API when Talend, Mule, and WSO2 exist.
Each low-code system is focused on solving specific tasks: modeling and executing business processes, data modeling, designing and developing integrations, modeling games, designing front-end interfaces, etc.
The concept of low-code has been known since the 90s. Still, it has become especially relevant since it allows you to shorten the time-to-market period, speed up the development of new business processes, and make changes to existing ones.
In low-code, the need for developers to adjust business requirements is minimal. They are focused on the implementation of new constructor elements and the configuration of the primary value to validate constructor elements. Here, the first enterprise-business objection appears.
Objection #1: “Our processes are too specific”
There are no identical companies. The same business processes, even for companies in the same segment, can be built using different logic. Therefore, it is easy for us to understand the fears of the product owner that the low-code constructor is not enough for the functionality he needs. Indeed, low-code provides more flexibility in implementing specific processes compared to code-first.
Imagine that you have chosen the code-first paradigm and are working with one particular box or developing it. It is saturated with certain entities, functionality, and terms. The more powerful the initial functionality ef-from the box, the more challenging it will be to modify the system later. The more changes you make, the fewer people will understand what works and how. The complexity of the changes will increase, and it doesn’t matter if your architecture is microservice or monolithic-modular.
Responsibility for the result will be clouded. To the claim: “Why did you make it uncomfortable?” — developers will answer: “Why did you describe the requirements unclear?” Developers can become overwhelmed by change requests, and some business requirements may be ignored. The development team may become a bottleneck for all changes. That is why it’s essential to consider this when building other processes, according to the theory of constraints.
While you don’t use one part of the functionality of-from the box, another part will suit you when adapting business processes to the box. As a result, new terms unique to your business will appear. In some cases, the management interfaces will be excessively complex. In other cases, you will have to put up with some nuances.
Indeed, it can be argued that such products contain “best practices.” However, these practices may not fit with the current culture of the company, and as a result, “best practices” turn into a cargo cult.
Compare this to working in the low-code paradigm. Low-code solutions do not offer “best practices”: with the help of a constructor, you design a solution that best suits your business.
At the same time, the developers are not focused on endless minor edits. They are engaged in new functionality and new elements of designers and explore engineering approaches. Development every day makes the constructor more diverse and convenient for business.
As for “best practices,” many low-code solutions have already built applications, such as CRM or ready-made integrations. But at the same time, ready-made solutions are rarely a fixed system feature — everything can be changed. Concerns about system attributes and the challenges of redefining a box component are no longer an issue.
Objection #2. “Licenses for low-code systems are expensive”
Low-code platforms have several monetization models. For example, in Talend, monetization is carried out at the expense of developer places: it doesn’t matter how many integrations you already have running. What matters is how many people are working on making changes to them. At the same time, on the productive server circuit, licensed parts are not required.
And some of the solutions are SaaS and are paid for by users. Let’s take a look at this particular case.
A different perception of the costs of licenses and development makes it difficult to compare them without prejudice. The purchase of licenses and payment for the development stream through different “task centers” affecting the project’s economics differently. This makes it difficult to compare costs on a parity basis; within a project, the cost of licenses seems more noticeable.
Licenses are cheaper than development from scratch. When you buy a license for any product, whether a low-code or not, you pay for a finished product to solve problems. As a rule, the cost of a license is lower than that of a project to create a self-written product with similar content and functionality. When it comes to low-code solutions, evaluating the functionality of a constructor is easier than understanding the nuances of a pre-made functionality, making the risk of functionality mismatch with tasks irrelevant.
Licenses have a simple economy without uncertainty. Vou immediately understand how much you will pay for the number of users of a low-code solution. And how much you have to pay to develop new functionality is difficult to guess in advance. After all, you need to consider the labor costs of the product owner and the long waiting time for the functionality. Often, developer salaries are not included in the functionality budget. Situations happen when a large business does not even consider these costs, and they are muddied in the overall budget.
In low-code, you buy not only visual development tools but also the best practices of process design. No one except you knows how to build a business process in your organization best. But at the same time, there are practices for implementing typical actions to help you create a more transparent and manageable process in fewer iterations.
For example, low-code ESB systems set some integration design patterns regarding logging, thinking in terms of “flow” / “line,”, etc. Low-code business processes set the standards for process design. By developing a similar business process, you will likely come to the same practices, but not immediately.
Recall, for example, how often your managers use BPM N to coordinate processes. And the use of LCAP allows you to shorten the path to finding the optimal solution at times.
Objection #3: “Everything is in the cloud, it’s insecure”
We encounter this objection quite often. Businesses are concerned that a low-code solution is stored “somewhere in the cloud, on someone’s servers, out of our control.”
There are several answers to this objection. Firstly, not all low-code systems must be deployed in the cloud. The providers of these solutions give the customer a choice: a cloud solution or a solution within your ecosystem, and some of the solutions are even open source (Strapi, Pimcore, Corteza, Builder).
It is usually more expensive to deploy software on servers within a company’s network, but the option is still available.
Furthermore, even cloud-based solutions may have the option to be placed on private clouds. For instance, Power BI from the Microsoft ecosystem provides such an alternative. Your Power BI can be hosted on dedicated servers of the Azure platform, which are located in a separate section of the data center.
E-commerce low-code also has strategies whereby they can provide private clouds to customers. If you decide to rebuild in-house development into a low-code paradigm, then in terms of security, nothing changes at all.
Objection #4: “The concept of low-code is not meant for high-load projects”
Quite the contrary: many low-code systems are designed to work with high load by default. Processing thousands of requests per second is not critical for them. Such solutions include, for example, Talend, Honeycode, Creatio, Strapi, and Pimcore.
We also need to consider the reverse side of the coin. A high-load development may have excessive legacy code, making refactoring difficult and costly. In contrast, many low-code designers debug the speed. Here, it is necessary to note that low-code can many technical problems. But neither the concept of low-code nor the code-first paradigm is spared secured from design errors of information models, business processes, and other things affecting the final performance.
One caveat: business sometimes has a different idea of what the high load is. It reaches out to an IT contractor with a request for a high-load project, but in practice, we are talking about a large division with severe turnover.
For instance, a B2B portal serving 3,000 customers daily or a B2C online store with a million monthly visitors cannot be considered a high load. There are no tens of thousands of simultaneous complex writing transactions, and, most likely, won’t happen shortly.
Until your project reaches the conditional limit of 5000 transactions per second, it’s too early to worry about whether the selected systems support a high load. It is better to focus on other issues and business goals.
But even if you have a high-load project, this does not exclude the possibility of using low-code. We know many large ecosystems are built from small “pieces”. For example, Tinkoff has many separate BPMS (Camunda) systems, and every system works with its own set of business processes. This was done not because the chosen solution couldn’t handle high load but rather for better control and fault tolerance.
Which projects are not suitable for low-code
The concept of low-code is quite universal. Sure, you need to study capabilities and analogs to select a specific solution, but low-code doesn’t differ from other concepts.
However, there are situations when the very concept of low-code may not suit the business.
1. If you are ready to adapt to the existing box. This item usually includes secondary business processes and any “liabilities”. For instance, it doesn’t matter how adaptable our payroll system is or how we configure ACS if this flexibility doesn’t result in any business growth.
2. The development of fundamentally new (innovative) technological solutions in some cases cannot be implemented in the low-code philosophy. It is important to understand the following: we are talking about technological innovations here and not about inventions in the business models.
3. If you are an IT team and it is difficult for you to guide employees to a new level of abstraction, further maintenance and changes to the project are not implied.
4. If you do not have time to rebuild (the project needs to be launched “yesterday”) or faced a massive legacy of old code.
5. If you have no choice. For example, you are part of a corporation, and the technologies are selected from upstream. So, many headquarters use Magento e-commerce standards, and regional offices are also forced to use Magento.
6. If you want to maintain the status quo and any paradigm change contradicts your goals.
