From Low-Code Anarchy and Legacy Dictatorship to a Managed Process Democracy

Low-code is no longer a novelty or just a trend– today, nearly every other (if not every) platform offers low-code development capabilities. But despite its popularity, low-code isn’t always beneficial by default. We explore why, in conversation with ELMA Executive Director Natalia Dolzhenkova.

Stages of Evolution

It is hard to imagine today, but there was a time when systems were monolithic and their development was carried out by software engineers with an academic education. Back then, if a business needed “something special”, it had to draw up a detailed technical specification, describe the technical setup and wait until the long-awaited feature, whose path was quite non-trivial, was carried out through the entire release cycle.

Case Study: " The Accounting Button" in the Age of IT Dictatorship

Imagine a large industrial holding. The chief accountant discovers that in order to generate a new mandatory report for the tax office, they have to manually consolidate data from three different sections of their old ERP system. This process takes two days every quarter and is prone to human error. Clearly, a new feature is needed error. how that feature request typically played out:

1. Request. The accounting department drafts an internal memo to the IT department with a request to "make a button that generates a report."

2. Business Analysis (1-2 months): The IT business analyst holds a series of meetings with the accounting department to create a formal 30-page technical specification (TS), detailing every column, formula, and data source.

3. Estimation and planning (1 month). The development manager reviews the technical specifications, understands that this will affect the core of the system, and schedules it for a release plan in six months, since the current release cycle is already frozen.

4. Development and testing (2 months). Developers write the code. QA engineers test it in a staging environment.

5. Deployment. In this mode, you can reach this stage after 9-10 months. During a scheduled maintenance window, the update is "rolled out" to the main server.

And here is the moment of happiness – the user has the long-awaited button in his hands. But there’s a catch: it doesn't quite work the way users expected. And as for revisions? That means starting the entire process over again.

What is good in this situation is the responsibility of the business for creating and providing jobs for local employees. As they say, factories for the workers, and coding for the developers. On a more serious note, this approach has a few tangible benefits:

• The business does not pay anyone except its own developers or those who are conditionally hired by them;

It gets exactly what it specified – nothing more, nothing less.

So Why Call It a dictatorship? Each expansion of functionality has to pass through a group of people, or more specifically, the IT department. They, as usual, are not very controllable by the business user. As a result, it turns out expensive, slow, but usually reliable. And that might have been perfectly fine… in a world where businesses could afford to remain unchanged for years at a time. But that world no longer exists.

That’s when someone enterprising came up with the concept of rapid prototyping. If you delve into history, there was no single genius inventor: the first cracks in the IT dictatorship appeared back in the 90s with the help of rapid development tools (RAD), which allowed developers to assemble applications from pre-built components. And the trendy label "low-code" was attached to all this guerrilla warfare in 2014 by analysts from Forrester, simply giving an official name to the anarchy that had begun long ago. Case Study: “Sales Department Optimization” in the Age of Anarchy

A trading company is implementing a new CRM with a powerful low-code builder. The head of the sales department, an energetic and inspired person, decides to "fine-tune " the system independently, without involving IT.

Here’s what happens in a month:

• Customer Profile. 40 new fields are added to the customer card using drag-and-drop interface: "Zodiac sign", "Favorite drink", "Cat's birthday", "Mood During Last Call ", etc. Most of these fields are optional and rarely used.

• Business processes. 15 parallel business processes are configured. One sends an SMS to the customer if they haven’t been called in 3 days. Another assigns a task to the manager if the “Mood” field isn’t filled out. A third automatically changes the status of the deal when an email is opened.

• Result: The system starts to slow down due to an overloaded customer card. The processes begin to conflict with one another: customers start receiving 5 different notifications per day. New managers are confused about which of the 40 fields are actually required. It is impossible to collect data for analytics, due to scattered, inconsistent data.

And so, it seems to be different, but now those same IT people don't like it – because it all changes quickly and sometimes even works, but it's hard to maintain such a setup. In the old days – slow as it may have been, with all the back-and-forth – your trusted in-house IT team would eventually deliver exactly what was asked, exactly how it was asked. But with this new “low-code beast,” there are built-in limitations. And now it's not people who are causing trouble, but their own self-created "Frankenstein".

Of course, there are advantages too. In our world, where business is in a constant state of turbulence and not always ideal, adaptability is still a valuable trait. If you can change along with the changing world and do it faster than your competitors, you can tolerate anarchy for a while. You can, but only for a while.

Bottom line: this still isn’t the perfect solution. Evolution of tools

It is important to understand that not every platform has gone through the evolutionary path. Some still operate with outdated approaches, offering only the illusion of simplicity and flexibility. Such tools are more reminiscent of chaos than a well-thought-out development system. Others disguise themselves as user-friendly low-code solutions, hiding behind an attractive shell the need to involve the vendor-certified developers. It may look like low-code, but without an integrator you can’t do anything.

An example of a "wolf in sheep's clothing"

A company buys a platform for business process automation. The marketing materials show a beautiful visual editor where you can draw workflows with a mouse. Marketers and analysts are delighted. They draw an ideal contract approval flow. But when it comes to action – say, at the step "Send contract data to 1C" – it turns out that there is no built-in block for this. The "Configure integration" button leads to the form "Leave a request, and our specialist will contact you to provide a cost estimate of integration work." As a result, each step that goes beyond "send an email" or "assign a task" requires expensive revision by the vendor.

So What’s the Problem? Well, nothing really, but the TCO (Total Cost of Ownership) quickly climbs to sky-high levels.

Controlled car or how to choose low-code

To achieve what we call “managed democracy”, a modern platform must offer a mature set of features.

Role-based model: To Each Their Own

A role-based model is not just "admin/user". A mature role-based model is a flexible system of delimiting rights not only to access data, but also to make changes. Ideally, you should be able to define roles with varying levels of "creative freedom":

• The business user views and works within workflows, but cannot change anything.

• The process analyst can adjust things like approval stages for marketing campaigns or add fields to the marketing campaign cards, but cannot touch the processes of the finance department.

• The IT architect does not change the business logic, but is responsible for complex integrations and security. He can "publish" a new connector to the analytics system, which analysts can use as a ready-made component in their own workflows. The key feature is the "Sandbox"– a personal testing environment for analysts. Each analyst can make any changes, test them, and only after everything is working as intended, the analyst clicks the "Submit for IT Approval «. The IT specialist then reviews the changes to ensure they do not violate the overall architecture, and with a single button "publishes" them for all employees. This is This is what controlled democracy looks like. Platform Customization Level: How Many Layers Are in the Cake?

Pay attention to which elements are subject to configuration: objects, fields, processes or all together? It is necessary to understand whether an average employee is able to make changes, without special knowledge, and what happens if the built-in tools no longer suffice.

The optimal solution is a platform with multi--layered configuration. It should offer different levels of complexity so that every user can customize the system to their needs, regardless of their skill level.

Think of it as a “layered cake” of automation, where each tier serves a different type of user:

• No-code (for business users) is the icing on the cake, what catches the eye first and is accessible and liked by everyone. More specifically, it is made up of visual builders that require zero code. Example: the head of the HR department himself, drags and drops a new step “Security Clearance” to the hiring process and ticks the “Required” box. Or a Commercial Director adds a new field, “LTV,” to a partner profile and configures it with a simple formula: total value of all closed deals.

• Low-code is the filling. This is where the true power lies. With its help, you can configure those custom rules, workflows or forms that distinguish your work patterns from the work of other similar companies on the market – and they help you win. Low-code setup is already done by analysts and "advanced" users. More complex formulas in the Excel style, simple scripts or visual modeling (BPMN) appear here to describe complex logic. For example, a financial analyst sets up a rule: "If the amount in the invoice exceeds 1 million rubles and the client is new, then the approval process should go along the branch with the participation of the financial director." Or the analyst configures a more complex sequence that defines the exact order of production stages from procurement to delivery and logistics, taking into account the setting of access rights to the information needed at this stage, the role-based permissions, and the conditions for completing tasks.

• Code (for developers) is the classic sponge of this layered masterpiece. It is worth mentioning right away: it is not always required. There are a number of tasks solved by low-code and no-code platforms that do not require the introduction of heavy artillery. But if you need to implement a complex integration with a legacy system or develop a custom service from scratch, then this layer becomes the solid foundation. What's in it? Full access to the platform's API and SDK. If complex Python or C# code is needed to integrate with a legacy warehouse system, the developer can build this module, "package" it as a simple component and hand it off to analysts for use in the low-code layer.

Thus, the “IT dictatorship” turns into the creation of convenient tools for business.

An additional, yet critically important aspect – the cherry on top, so to speak – is version control and easy rollback. Any change made to the process (even at the no-code level) should be saved as a new version. If everything breaks after the “optimization” from the head of the sales department, the IT specialist should be able to log into the system, review the change history and roll back the process to yesterday’s stable version with a single click. This is your safety net against anarchy. For more complex and branching configurations, many vendors are increasingly implementing change delivery tools using CI/CD.

Managed IT Democracy: Summary

A mature approach to low-code in the corporate environment radically shifts the focus from the question “How fast can we build something?” to the question “How can we build quickly while creating a controlled and sustainable digital asset?” The answer lies in synergy: organizational changes (like creating a center of excellence) must be based on the right technological foundation. A strategy without instrumental implementation is just a declaration of intent. And a scattered set of powerful tools without a single strategy is a direct path to fragmented automation and technological chaos, which everyone is trying to avoid.

Only the fusion of a full-fledged strategy and the right toolset forms the supporting framework for a company’s entire digital evolution– one where speed no longer stands in opposition to reliability, and innovation becomes an organic part of corporate architecture.

That is why choosing the right platform isn’t just important – it’s mission-critical. It should not be a toolbox of disconnected constructors, but a cohesive environment, which is essentially an "industrial-grade sandbox": one that empowers the business with creative freedom, while keeping everything securely within the governance boundaries set by the IT department.

Such a platform becomes an integral part of the existing IT landscape, not disrupting it, but enriching it. It is capable of stitching together end-to-end processes passing through several legacy systems into a single digital canvas and serving as a common language for business and IT. Ultimately, this is not just an investment in short-term automation, – it’s an investment in the operating system of your digital transformation itself – a launchpad from which the company can take fast and confident steps into the future.