Is it true that No/Low-code cannot be used in enterprise solutions?
Forbes calls low-code a trend in the first lines, IDC statistics speak in favor of using low-code, and the low rate of change in traditional development poses a threat to business. But despite all this, the enterprise-scale business is wary and even mistrustful of the low-code paradigm. According to its representatives, applied development for large companies can be carried out either on boxed solutions or from scratch. And the low-code toolkit “does not correspond to the scale of enterprise tasks and does not provide a sufficient level of protection for commercial information.”
Maksym Prokhorov CEO & Co-founder at PLATMA
Today we will analyze the main objections to the use of low-code systems in an enterprise-scale business and find out how fair they are. A little about the low-code paradigm.
Businesses need to make adjustments regularly. Sometimes minor, like adding an attribute or moving a button, and sometimes 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 edits 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 such constructors already exist: 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 certain 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, but now 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 needed to implement new constructor elements and to configure the primary value to validate constructor elements. This is where the first enterprise-business objection comes in.
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. In fact, code-first limits the ability to implement specific processes more than low-code.
Let’s imagine that you choose the code-first paradigm and work with a certain box or develop this box. It is saturated with certain entities, functionality, and terms. The more powerful this starting functionality of the box, the more difficult it will be to make changes to the system. The more changes you make, the fewer people will understand what works and how: the complexity of the changes you make will increase, and it doesn’t matter if your architecture is microservice or monolithic-modular.
Responsibility for the result will be blurred. To the claim: “Why did you make it uncomfortable?” — developers will answer: “Why did you describe the requirements so badly?” Developers will drown in change requests, business will ignore some of the requirements. The development team will become the “bottleneck” of all changes — therefore, according to the theory of constraints, you will have to build other processes with this in mind.
You will not use part of the functionality of the box, another part will suit you when adapting business processes to the box. As a result, new terms that are not typical of your business will appear. In some cases, the management interfaces will be excessively complex, and in some cases, you will have to put up with some nuances.
Yes, it can be argued that in such products there are “best practices”. However, these practices may not fit with the current culture of the company, and as a result, “best practices” will 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. Objections about system attributes and the complexity of redefining a part of the box are a thing of the past.
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, in the productive server circuit, you do not have licensed parts.
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 objectively. The purchase of licenses and payment for development go through different “task centers” and affect the economics of the project in different ways. This makes it difficult to compare costs on a parity basis; within a project, the cost of licenses seems to be more noticeable.
Licenses are cheaper than development from scratch. When you buy a license for any product, whether it’s low-code or not, you pay for a finished product that you use 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. And in the case of low-code solutions, the risk of functionality mismatch with tasks is irrelevant: it is easier to evaluate the functionality of a constructor than to find out all the nuances of a ready-made functionality.
Licenses have a simple economy without uncertainty. You immediately understand how much you will pay for the number of users of a low-code solution. And how much you have to pay for the development of new functionality, is difficult to guess in advance. After all, you need to take into account the labor costs of the product owner and the long waiting time for the functionality, often even the salaries of the company’s developers are not part of the functionality’s budget. It happens that a large business does not even consider these costs, and they are blurred in the overall budget.
In low-code, you buy not only visual development tools but also the best practices of process design. No one can know how best to build a business process in your organization. But at the same time, there are practices for implementing typical actions that will help you build a more transparent and manageable process in fewer iterations.
For example, low-code ESB systems set some integration design patterns in terms of logging, thinking in terms of “flow” / “line”, etc. Low-code business processes set the standards for process design. By developing a similar business process on your own, you are likely to come to the same practices, but not immediately.
Recall, for example, how often your managers use BPMN 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 about the fact that a low-code solution is stored “somewhere in the cloud, on someone’s servers, we don’t control it.”
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). Usually, a license for deployment on servers in the company’s circuit is more expensive, but there is still such an opportunity.
Secondly, even cloud solutions can potentially be placed on private clouds. Such an option, for example, is offered by Power BI from the Microsoft ecosystem: “your” Power BI can be hosted on dedicated servers of the Azure platform, in a separate part of the data center.
e-Commerce low-code also has plans whereby they can provide private clouds to customers. If you decide to rebuild in-house development into a low-code paradigm, then from the point of view 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 notice the opposite: often an exclusive development, in theory, designed for high loads, has a huge amount of legacy, which is difficult and expensive to refactor. In contrast, many low-code designers debug the speed of components over and over again. Here it is necessary to make a reservation that low-code can get rid of many technical problems, but neither the concept of low-code nor the code-first paradigm is spared from design errors of information models, business processes, and other things that also affect the final performance.
One caveat: business does not always have a correct idea of what high load is. He turns to an IT contractor with a request for a high-load project, but in practice, it turns out that we are talking about a large division with a serious turnover. For example, a B2B portal that serves 3,000 customers a day, or a B2C online store with a million visitors a month, doesn’t even come close to being considered a high load. There are no tens of thousands of simultaneous complex write transactions and, most likely, there will not be soon.
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 concentrate 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 fairly large ecosystems that are built from small “pieces”. For example, Tinkoff has many separate BPMS (Camunda), and each of the systems works with its own set of business processes. This was done not so much because the chosen solution “will not pull” high load, but for better control and fault tolerance.
Which projects are not suitable for low-code
The concept of low-code is quite universal. Yes, to select a specific solution, you need to study its capabilities and analogs, but low-code is no different 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 example, what difference does it make how flexible our payroll is or how ACS is configured, if this flexibility does not have any business multiplier?
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 that we are talking about technological innovations here and not innovations in the field of business models.
3. If you are an IT team and it is difficult for you to retrain 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 you are faced with a huge legacy of old code.
5. If you have no choice. For example, you are part of a corporation, and the set of technologies is set from above. So, many headquarters use Magento as the e-Commerce standard, and regional offices are also forced to use Magento.
6. If you want to maintain the status quo and any paradigm change go against your goals.
