Is it true that low-code can't be used in enterprise solutions

Hallo. I'm Andrey Putin, managing partner of IT integrator kt.team. Recently, we have been increasingly offering our large customers to use low-code solutions in IT architecture. Their functionality allows you to quickly make changes to integrations and business processes. This is critical for business, given the dynamics of changes in the market.

Forbes calls low-code a trend in the first lines, he speaks in favor of using low-code IDC stats, and the slow rate of change in traditional development is a threat to business. But despite all this, enterprise-scale businesses are cautious and even suspicious of the low-code paradigm. According to its representatives, application development for large companies can be carried out either on packaged 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.”

Today we will look at the main objections to the use of low-code systems in enterprise-scale businesses and find out whether they are fair.

‍

A little bit about the low-code paradigm

Businesses regularly require some edits. Sometimes minor ones, such as adding an attribute or moving a button, and sometimes more significant ones, requiring the development of something fundamentally new.

In the traditional code-first paradigm, the developer develops the functionality and makes all the edits. At the same time, everyone loses. Developers — because as the project grows, they focus more on minor edits and less on reusable code. Business — because we have to wait for a change. We know of cases when developers are busy making minor improvements, while the company's waiting list is accumulating 50 or more projects.

In the low-code concept, a developer does not create final value, but a constructor for assembling it. It's faster and easier to collect or reconfigure value in a designer: this can be done not only by developers, but also by business analysts or end users with development skills (what Gartner calls citizen developers). Moreover, for some tasks, such constructors already exist: for example, it is pointless to create an integration builder or API when they exist Talend, Mule, WSO2.

Each low-code system is focused on solving certain specific problems: modeling and executing business processes, modeling data, designing and developing integrations, modeling games, designing front-end interfaces, etc.

Low-code concept It has been known since the 90s, but now it has become especially relevant because it reduces the time to market period, accelerates the development of new business processes and makes changes to existing ones.

In low-code, the need for developers to adjust business requirements is minimal. They are needed to implement new design elements and to configure the primary value in order to verify the correctness of the designer elements.

This is where the first objection of the enterprise business comes from.

Objection No. 1. “Our processes are too specific”

No company is the same. Even for companies in the same segment, the same business processes can be built using different logic. Therefore, it is easy for us to understand the concerns 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.

If you choose the code-first paradigm, you're working with a box or developing that box. It is full of certain entities, functionality, and terms.

The more powerful this box's starter functionality, the more difficult it will be to make changes to the system. The more changes you make, the fewer people will actually understand what works and how: the complexity of the changes you make will increase, regardless of whether your architecture is microservice or monolithic modular.

Responsibility for the result will be blurred. To the claim: “Why did you make it inconvenient?” — developers will answer: “Why did you describe the requirements so poorly?” Developers will drown in change requests; businesses will ignore some of the requirements. The development team will become the bottleneck of all changes, so, according to the theory of constraints, you will have to build other processes taking this into account.

You will not use some of the box's functionality, and another part will suit you when adapting business processes to the box.

As a result, new terms that are not typical for your business will appear. In some cases, management interfaces will be excessively complex, and in some cases you will have to put up with some nuances.

Yes, one could argue that such products are “best practices”. However, these practices may not correspond to the company's current culture, and as a result, “best practices” will become 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 designer, you design a solution that best suits the specifics of your business.

At the same time, developers are not focused on endless minor edits. They are working on new features and new design elements, and exploring engineering approaches. Every day, development makes the designer more diverse and convenient for business.

As for “best practices”, many low-code solutions have already designed applications, such as CRM or ready-made integrations. At the same time, ready-made solutions are almost never a fixed system feature — everything can be changed. Objections about system attributes and the difficulty of redefining part of the box are becoming a thing of the past.

Objection No. 2. “Low-code system licenses are expensive”

Low-code platforms have several monetization models. For example, in Talend, monetization is done at the expense of developer positions: it doesn't matter how many integrations you have already launched, it's important how many people are working to make changes to them. At the same time, you do not have licensed parts in the productive server circuit.

And some of the solutions are actually SaaS and are paid per user. Let's look at this particular case.

1. Different perceptions of license and development costs make it difficult to compare them objectively.

Licenses are purchased and development payments are paid for in different “task centers” and have different effects on the project's economy. This makes it difficult to compare costs on a parity basis; under the project, the cost of licenses seems to be more noticeable.

‍

2. Licenses are cheaper than developing from scratch.

When you buy a license for any product — it doesn't matter if it's low-code — you pay for the finished product that you will use to solve problems. As a rule, the license cost 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 the functionality not meeting the tasks is irrelevant: it is easier to evaluate the functionality of a designer than to learn all the nuances of ready-made functionality.

‍

3. Licenses have a simple economy without an uncertainty factor.

You can immediately understand how much you will pay for the number of users of the low-code solution. And it is difficult to predict in advance how much you will have to pay for developing new features. After all, you need to take into account the product owner's labor costs and the longer waiting time for functionality; often even the company's developers' salaries are not part of the functionality budget. You can read more about the economic component of development in the article”IT investments”. It happens that big businesses don't even consider these costs, and they are blurred into the overall budget.

‍

4. At low-code, you buy not only visual development tools, but also process design best practices.

No one can know what is the most convenient way to build a business process in your organization. But at the same time, there are practices for implementing standard 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 standards for process design. When developing a similar business process on your own, you are likely to come to the same practices, but not right away. Remember, for example, how often do your managers use BPMN to coordinate processes? And the use of LCAP makes it possible to shorten the path to finding the optimal solution by several times.

Objection No. 3. “It's all in the cloud, it's not secure”

We face this objection quite often. Businesses are concerned that the 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.

First of all, not all low-code systems need to 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 within a company is more expensive, but this is still possible.

Second, even cloud solutions can potentially be hosted on private clouds. This option, for example, is offered by Power BI from the Microsoft ecosystem: “your” Power BI can be hosted on dedicated Azure servers, in a separate part of the data center.

E-commerce low-code also has plans that allow them to provide customers with private clouds.

If you yourself decide to rebuild in-house development into a low-code paradigm, then nothing changes at all from the point of view of security.

Objection No. 4. “The low-code concept is not intended for highload projects”

On the contrary: many low-code systems are designed to work with highload by default. Processing thousands of requests per second is not critical for them. Such solutions include, for example, Talend, Honeycode, Creatio, Strapi, Pimcore.

We notice the opposite: often exclusive development, designed in theory for high loads, has a huge legacy that is difficult and expensive to refactor. In contrast, many low-code constructors debug component speed over and over again. It should be noted here that low-code can get rid of many technical problems, but neither the low-code concept nor the code-first paradigm is spared from errors in designing information models, business processes, etc., which also affect the final performance.

One caveat: businesses do not always have a correct idea of what highload 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 significant 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 what is commonly considered highload. There are no tens of thousands of complex recording transactions at the same time and, most likely, there will be no such transactions in the near future.

Until your project reaches the conditional limit of 5,000 transactions per second, it's too early to worry about whether your chosen systems support highload. It is better to focus on other issues and business goals.

But even if you really have a highload 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), each of which works with its own set of business processes. This was done not so much because the chosen solution would not “fit” highload, but for better control and resiliency.

What projects low-code is not suitable for

The low-code concept is quite universal. Yes, to choose a specific solution, you need to study its capabilities and analogues, but this low-code does not differ from other concepts.

However, there are situations where the low-code concept itself may not be suitable for business.

‍

1. If you're ready to adapt to your existing box. This item usually includes secondary business processes and any “liabilities”. For example, what difference does it make whether we calculate salaries flexibly or configure access control systems if this flexibility does not have any multiplier for business?

2. In some cases, the development of fundamentally new (innovative) technological solutions cannot be implemented in low-code philosophy. It is important to understand that this is about technological innovations, 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, and further support and changes to the project are not meant.

4. If you don't have time to rebuild (you need to launch the project “yesterday”) or you're faced with a huge legacy of old code.

5. If you don't have a choice. For example, you're part of a corporation, and the set of technologies is listed above. For example, many headquarters use Magento as an e-commerce standard, and regional offices are also forced to use Magento.

6. If you want to maintain the status quo and any paradigm changes go against your goals.

‍