Is It True That Low-Code Cannot Be Used in Enterprise Solutions: Analysis of the Main Objections
Recently, we have been offering our major clients to use low-code solutions in their IT architecture. Functionality of such solutions allows users to make quick changes to integrations and business processes. This feature is critical for businesses, given the dynamics of changes in the market.
Forbes has called low-code a top trend, IDC statistics supports the low-code use, and the low speed of changes in traditional development doesn't look promising for the business. But despite all this, an enterprise-scale business is suspicious and distrustful of the low-code paradigm. According to its representatives, the applied development for major companies can be implemented either using the packed solutions, or from scratch. And the low-code toolkit "does not correspond to the scale of enterprise-level tasks and does not provide sufficient protection of classified information."
This time we will analyze the main cons of using the low-code systems for enterprise-scale businesses and will see if they're justified.
A Few Words about the Low-Code Paradigm
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 шmprovements, 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.
Objection No. 1 "Our Processes Are Very Specific"
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.
Objection No. 2 "Licenses for Low-Code Systems Are Expensive"
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.
Red Hat Fuse
Up to $12,000 annually per user. The cost of the most complete version of Talend Data Fabric is calculated individually.
Studio is an open source product. Separate components (Anypoint MQ, etc.) — a paid annual subscription.
An annual license for two users costs $22,800.
An annual license cost starts at $9504.
And some of the solutions are actually SaaS and are paid for by users. Let's analyze this particular case.
Different perceptions of license and development costs complicate their objective comparison.
The license purchasing and paying for development is processed in different task centers and have different financial impact on the project. This makes it difficult to compare costs on an equal footing, as within the framework of the project, buying a license will seem more expensive.
Buying a license is cheaper than developing from scratch.
When you buy a license for any product – no matter if it is low-code or not you pay for the finished product that you will use to solve problems. As a rule, the license is cheaper than a project for developing your own product with similar content and features. And speaking about the low-code solutions, there is no risk of discrepancies between the functionality and the tasks: it is easier to evaluate the functionality of the builder than to estimate all the details of a ready-made functionality.
The license economy is simple and transparent.
From the beginning you clearly see how much you have to pay for the number of the low-code solution users. Whereas, it is hard to predict how much you will have to pay for the development of new functionality. After all, you need to take into account the work input of the product owner and the time it takes to develop the functionality. Often even the developers' salaries are not included in the allocated functionality budget. You can find more information about the financial aspects of the development in the article "Investments in IT". Sometimes, big businesses do not even calculate such costs, and they are blurred in the total budget.
In the low-code, you pay not only for some visual development tools, but for the best practices in the process design.
No one can tell you the best way of building a business process in your organization. Meanwhile, there are some standard procedures 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, employing such terms as "flow" and "line" , etc. Low-code business processes set the process design standards. If you develop a similar business process by yourself, you will probably end up using the same practices, though it will take time. Remember, for example, how often do your managers use BPMN for process coordination? Whereas the use of LCAP helps finding the optimal solution much faster.
Objection No. 3 "Everything's In the Cloud, It's Not Safe"
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.
Objection No. 4 "The Low-Code Concept Is not Designed for High-Load Projects”
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.
When Low-Code Approach Is Not Suitable
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.
If you are ready to adapt to the out-of-box solution. This item usually includes side-line business processes and all kinds of passives. For example, does it really matter how flexible the wage calculations or ACS configurations are, if this flexibility has no multiplier in business?
In some cases, the development of fundamentally new (innovative) technological solutions cannot be implemented in the low-code philosophy. It is important to understand that we are talking about technological innovations, and not about innovative business models.
If you are an IT team and it will be challenging to retrain employees to a new level of abstraction, and further support and changes to the project are not planned.
If you don't have time for resetting (you're facing tight deadlines) or you deal with a huge legacy code.
If you have no choice. For example, you are part of a corporation, and the management has provided for a mandatory set of technologies. For example, many headquarters use Magento as an e-Commerce standard, and regional offices also have to use Magento.
If you want to maintain a status quo and any changes in the paradigm go against your goals.