Is It True That Low-Code Can't Be Used in Enterprise Solutions?

Objection No. 1. "Our processes are too specific"

Objection No. 2. "Low-code system licenses are expensive"

Objection No. 3. "Everything is in the cloud, so it is not secure"

Objection No. 4. "The low-code concept is not meant for high-load projects"

Which Projects Low-Code Is Not Suited For

Reading time: 9 min. Hi, I am

Andrey Putin, Managing Partner at kt.team, an IT integrator. Lately, we have been increasingly recommending low-code solutions in IT architecture to our large clients.

Their functionality makes it possible to quickly change integrations and business processes.

But despite all this, enterprise-scale businesses approach the low-code paradigm with caution and even skepticism.

According to its proponents, application development for large companies can be done either on off-the-shelf solutions or from scratch.

And low-code tooling "does not match the scale of enterprise tasks and does not provide an adequate level of commercial data protection."

Today we will examine the main objections to using low-code systems in enterprise-scale businesses and find out how valid they are.

That is why it is easy to understand the product owner's concern that a low-code builder may not be enough for the functionality they need.

In practice, code-first limits the implementation of specific processes more than low-code does.

If you choose a code-first paradigm, you either work within a packaged solution or build that package yourself.

It is filled with specific entities, functionality, and terminology.

The more powerful the initial out-of-the-box functionality is, the harder it will be to make changes to the system.

The more changes you make, the fewer people will even understand what works and how:

• the complexity of changes will increase
• and it does not matter
• whether your architecture is microservices-based
• monolithic-modular

Responsibility for the result will be blurred. In response to the complaint: "Why did you make it so inconvenient?"

- developers will ask: "Why did you describe the requirements so poorly?"

Developers will drown in change requests, and the business will ignore part of the requirements. The development team will become a 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 off-the-shelf functionality, and another part will only fit if you adapt your business processes to the product. As a result, new terms that are not native to your business will appear; in some cases, the management interfaces will be unnecessarily complex, and in others you will have to live with certain nuances. Yes, one could argue that these products embody "best practices."

However, these practices may not match the company's current culture, and as a result, the "best practices" will turn into cargo cult.

At the same time, developers are not focused on endless minor fixes.

They work on new functionality and new builder components, and they explore engineering approaches.

Development makes the builder more diverse and more convenient for business every day.

As for "best practices," many low-code solutions already include prebuilt applications, such as CRM systems or ready-made integrations.

At the same time, off-the-shelf solutions are practically never a fixed system characteristic - everything can be changed.

Concerns about system attributes and the difficulty of overriding parts of the out-of-the-box product are fading.

Different perceptions of license and development costs make it hard to compare them objectively. License purchases and development payments go through different budget centers and affect project economics differently. This makes it difficult to compare costs on equal terms; within a project, the cost of licenses often seems more noticeable.

There are several answers to this objection. First, not all low-code systems have to be deployed in the cloud.

Vendors of these solutions give the customer a choice:

• a cloud solution or a solution within your ecosystem
• and some solutions are even open source (Strapi
• Pimcore
• Corteza
• Builder)

Usually, a license for deployment on servers within the company environment costs more, but that option still exists. Second, even cloud solutions can potentially be hosted in private clouds.

For example, Power BI from the Microsoft ecosystem offers this option: "your" Power BI can be hosted on dedicated Azure servers, in a separate part of the data center. e-Commerce low-code vendors also have plans that would allow them to provide customers with private clouds.

If you decide to rebuild in-house development around a low-code paradigm, then from a security standpoint nothing changes at all.

Quite the opposite: many low-code systems are designed for high-load use by default.

We see the opposite: custom development, which in theory is intended for high loads, often comes with a huge amount of legacy code that is difficult and expensive to refactor. By contrast, many low-code builders keep refining component performance again and again.

It should be noted that low-code can eliminate many technical problems, but neither the low-code concept nor the code-first paradigm protects you from mistakes in designing information models, business processes, and other factors that also affect final performance.

One nuance: businesses do not always have a correct understanding of what high load means.

They approach an IT contractor with a request for a high-load project, but in practice it turns out to be a large division with substantial turnover. For example, a B2B portal serving 3,000 customers a day or a B2C online store with one million visitors per month does not even come close to what is commonly considered high load.

There are no tens of thousands of simultaneous complex write transactions here, and there most likely will not be in the near future.

Until your project reaches the notional threshold of 5,000 transactions per second, it is too early to worry about whether the selected systems support high load.

It is better to focus on other issues and business goals.

But even if you truly have a high-load project, that does not rule out the use of low-code.

We know of fairly large ecosystems built from small pieces. For example, Tinkoff has many separate BPMS instances (Camunda), and each system works with its own set of business processes.

This is done not so much because the chosen solution cannot handle high load, but rather for better control and fault tolerance.

In some cases, the development of fundamentally new (innovative) technological solutions cannot be implemented in a low-code philosophy. It is important to understand that this refers specifically to technological innovation, not innovation in business models.

If you are an IT team and it is hard to retrain employees to a new level of abstraction, and ongoing support and changes to the project are not expected.

If you do not have time to rebuild things from scratch (the project needs to launch yesterday) or you are dealing with a huge legacy codebase.

If you want to preserve the status quo and any paradigm shift goes against your goals.