Is It True That Low-Code Cannot Be Used in Enterprise Solutions: Analysis of the Main Objections

Business is an ever-changing environment that requires constant edits. Sometimes minor ones, such as adding an attribute or moving a button, and sometimes more significant, when something fundamentally new has to be developed.

In the traditional code-first paradigm, the developer is responsible for the functionality development and editing. In this case, everyone's a loser. Developers – because as the project grows, they are mostly focused on minor edits instead of code reuse. Business – because it has to wait for changes to be implemented. We know the cases when developers work on some minor improvements, whereas the company's waiting list has 50 or more projects on it.

In the low-code concept, the developer does not create the final value, but makes a builder for its assembly. Creating and reconfiguring a value in a builder is fast and easy: this can be done not only by developers, but also by business analysts or end users who have development skills (Gartner calls them "citizen developers"). Moreover, builders for some specific tasks have already been developed: for example, there is no need to make an integration or API builder as you can use Talend, Mule, WSO2 .

Each low-code system is designed to solve specific tasks: business process modeling and executing, data modeling, integrations design and development, games modeling, designing front-end interfaces, etc.

The low-code concept has been introduced in the 90s, but now it has particular relevance, since it reduces the time to market, accelerates the development of new business processes and changes of the existing ones.

In low-code, the need to engage developers to change business requirements is minimized. Instead, they help create new elements of the builder and configure the primary value in order to check the proper functioning of builder elements.

And here we come across the first objection of the enterprise-scale business.

Each company is unique. Similar business processes, even when used in companies from the same industry, can be based on different logic. Therefore, we can easily understand fears of product owners who think that low-code builder will not be able to ensure the required functionality.

But in fact, code-first puts more constraints on implementing specific processes than low-code.

If you choose the code-first paradigm, you either work with a out-of-box software or develop it. It is packed with certain entities, functionality, and terms.

The more functions the original package has, the more difficult it will be to make changes to the system. The more changes you make, the fewer people will generally understand the way it works: the changes you make will get more and more complex, and it doesn't matter whether your architecture is microservice or modular monolithic.

It will be hard to assign responsibility for results. In response to your claim: "Why is it so inconvenient?" – developers will say: "Why did you provide such a poor requirements description?" Developers will get lost in change-requests, the business will simply ignore certain requirements. As a result, the development team will become the bottleneck to all changes  therefore, according to the theory of constraints, you will have to take it into account when building other processes.

Some features in the package will not be used at all, others will only suit you if business processes are adapted to the package.

As a result, you'll have to introduce new terms you've never used before, sometimes the management interfaces will be excessively complex, and sometimes you will have to put up with certain limitations.

For sure, you can argue that such products incorporate the best practices. However, these practices may not correspond to the existing corporate culture, and even the best practices will turn into a cargo cult.

Compare this with the work in the low-code paradigm. Low-code solutions do not rely on the best practices: using a builder, you design a solution that will be most suitable for your business.

At the same time, developers are not exclusively focused on making minor edits. They develop new builder features and elements, and explore engineering approaches. Every day developers make the builder more diverse and convenient for business.

As for the best practices, many low-code solutions have ready-to-use apps, for example, CRM or ready-made integrations. Meanwhile, ready-made solutions are almost never a fixed system feature – there is always an opportunity for changes. Objections regarding system attributes and the complexity of resetting a part of the package are not longer relevant.

Low-code platforms have several monetization models. in Talend, for example, monetization depends on the number of developers: it doesn't matter how many integrations you have launched, – what really matters is how many people make changes to them. At the same time, you do not have any parts to be licensed in the production servers' contour.

And some of the solutions are actually SaaS and are paid for by users. Let's analyze this particular case.

That's a very typical objection. The business is concerned with the fact that the low-code solution is stored "somewhere in the cloud, on someone's servers, and is beyond our control."

There are several answers to this objection.

First, not every low-code system has to be deployed in the cloud. The providers of these solutions give customers a choice: a cloud solution or a solution within their ecosystem. Some solutions including Strapi, Pimcore, Corteza, Builder, etc. are open source. Usually, a license for deployment on servers in the company's contour is more expensive, but still there is such an opportunity.

Second, even the cloud solutions can be located in private clouds. Such an option, for example, is provided for by Power BI which is part of the Microsoft ecosystem: your Power BI can be hosted on dedicated servers of the Azure platform, in a separate part of the data center.

Moreover, e-Commerce low-code platforms have plans allowing them to provide private clouds to their customers.

If you want to change your in-house development to a low-code paradigm, this will make no difference from the point of view of security.

Just the opposite: many low-code systems are designed for the high load work by default. Processing thousands of requests per second is not critical for them. Such solutions include, for example, Talend, Honeycode, Creatio, Strapi, Pimcore.

Actually, it's quite the opposite: an exclusive development, theoretically designed for high loads, often has enormous legacy, which is difficult and expensive to refactor. In contrast, many low-code builders would configure the speed of components each time. Note that it's possible to tackle most technical problems in the low-code, but neither the low-code nor the code-first paradigm is spared from design errors in data models, business processes, and other things that have impact on the actual performance.

There is one point: business does not always understand what the high load is. They address an IT contractor with a request for a high load project, whereas in fact it's just a big department with a considersble turnover. For example, a B2B portal that serves 3,000 customers a day, or a B2C online store with a million visitors per month are very far from what is considered high load. These businesses do not come evn close to tens of thousands simultaneous complex transactions and, most likely, they won't be there in the near future.

Until your project reaches a conditional limit of 5000 transactions per second, there is no need to worry about your system's capacity for high load work. It is better to focus on other issues and business goals.

But even if you really run a high load project, you can still use the low-code. There are examples of major ecosystems that consist of small pieces. For example, Tinkoff ecosystem has many separate BPMSes (Camunda), where each system works with a separate set of business processes. In fact, it's not because the solution selected is insufficient for the high load, but as it ensures better control and fault tolerance.

The low-code concept is quite universal. Of course, you have to find information about its capabilities and analogues to choose a specific solution, but that's typical of any concept in general.

However, there are situations when the low-code concept itself is not a good choice.

Do you want to get more useful materials?
Subscribe to our newsletter!

News of the world of design and development, articles, and our latest cases. We write about complex things in simple words — without ads or spam.