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

Low-code is not news or a trend, today every second (if not the first) platform provides opportunities for low-code customization. Why this is not always for the good, we figure out with ELMA Executive Director Natalia Dolzhenkova.

Stages of development

It is hard to imagine today, but there was a world when systems were monolithic and their development was carried out by programmers with an academic education. In those days, in order to ask for “something special”, a business 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: "Accounting Button" in the Age of IT Dictatorship

Imagine a large manufacturing holding. The chief accountant discovers that to generate a new mandatory report for the tax office, he needs to manually combine data from three different sections of their old ERP system. This takes two days every quarter and is prone to errors. Of course, a new function is needed here.

The path to it looked like this:

1. Request. The accounting department writes a memo to the IT department with a request to "make a button that will generate a report."
2. Analytics (1-2 months): The IT analyst holds a series of meetings with the accounting department to create a formal 30-page technical specification (TS), which describes every column, every formula, and every data source.
3. Evaluation and planning (1 month). The development manager evaluates the technical specifications, understands that this will affect the core of the system, and sets the task in the release plan in six months, since the current release is already frozen.
4. Development and testing (2 months). Programmers write code, testers check it on a test stand.
5. Implementation. In this mode, you can reach this stage after 9-10 months. During the night technological 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. Only it doesn't look quite as expected. And what is a remake? Everything all 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 programmers. If we are a little more serious, then with this approach, the business:

• does not pay anyone except its own developers or those who are conditionally hired by them;
• gets exactly what he describes – no more, but no less.

Why dictatorship? Each expansion of functionality rests on 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, long, but usually reliable. And everything would be fine if we lived in a world where business can work for years without changes. But it is not so.

And then someone enterprising came up with the concept of rapid prototyping. If you delve into history, there was no lone hero-inventor: the first mines under the IT dictatorship were laid back in the 90s with the help of rapid development tools (RAD), which allowed programs to be assembled from ready-made cubes. And the fashionable 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: “Optimization” of the Sales Department in the Age of Anarchy

A trading company is implementing a new CRM with a powerful low-code constructor. The head of the sales department, an active and inspired person, decides to "tweak" the system for himself without involving IT.

What happens in a month:

• Client card. 40 new fields are added to the client card using drag-and-drop: "Zodiac sign", "Favorite drink", "Cat's birthday", "Mood at the last bell", etc. Most of them are not required to be filled in and are not used.
• Business processes. 15 parallel business processes are configured. One sends an SMS to the client if he has not been called for 3 days. Another assigns a task to the manager if he has not filled in the "Mood" field. The third automatically changes the status of the deal if the client opens the letter.
• Result: The system starts to slow down due to an overloaded card. Processes conflict with each other: clients receive 5 different notifications per day. New managers cannot understand which of the 40 fields really need to be filled in. It is impossible to collect data for analytics, as it is chaotic and incomplete.

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 system. Previously, albeit for a long time, albeit with bickering, but the dear IT person did everything you said and how you said, and now this low-code devil-machine has limitations. And now it's not people who are harassing business, but their own self-created "Frankenstein".

Of course, there are advantages too. In our world, where business is in a protracted storm and not always ideal, adaptability is still a good quality. 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 not for long.

In general, again not ideal.

Evolution of tools

It is important to understand that not every platform has gone through the evolutionary path. Some solutions remain at the level of an outdated approach, 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 convenient low-code solutions, hiding behind an attractive shell the need to involve the vendor developer specialists. That is, it seems to be 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 automating business processes. The advertising materials show a beautiful visual editor where you can draw process diagrams with a mouse. Marketers and analysts are delighted. They draw an ideal contract approval process. But when it comes to action – for example, to the step "Send data from the contract to 1C" – it turns out that there is no standard block for this. The "Configure integration" button leads to the form "Leave a request, and our specialist will contact you to estimate the cost of integration work." As a result, each step that goes beyond "send an email" or "set a task" requires expensive revision by the vendor.

What's wrong? Well, nothing really, only the figures in TCO (Total Cost of Ownership) will be sky-high.

Controlled car or how to choose low-code

To achieve that very “managed democracy”, a modern platform must have a set of mature functions.

Role model: Render to Caesar what is Caesar's, and to the mechanic what is the mechanic's

A role model is not just "admin/user". A mature role model is a flexible system of delimiting rights not only to access data, but also to make changes. In an ideal system, you can create roles with different levels of "creative freedom":

• The business user sees and works in the processes, but cannot change anything.
• A process analyst can change the stages of the advertising materials approval process, add fields to the marketing campaign card, 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 in their processes as a ready-made cube.

The key feature is the "Sandbox". The analyst has his own test copy of the process. He can make any changes, test them, and only after everything works, he clicks the "Send to IT for approval" button. The IT specialist checks that the changes do not violate the overall architecture, and with one button "publishes" them for all employees. This is democracy under control.

Platform Customization Level: How Many Layers Are in the Pie

Pay attention to which elements are subject to configuration: objects, fields, processes or all together? It is necessary to understand whether an ordinary employee is able to figure it out on his own, without special knowledge, and what will happen if the built-in tools are not enough.

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

Imagine a “layer cake” of automation, with many different tiers:

• 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 a set of visual designers where you don’t need to write a single line of code. Example: the head of the HR department himself, with the mouse, adds a new stage “Security check” to the hiring process and ticks the “Required” box. Or a new field “LTV” appeared in the counterparty card, which is calculated as the sum of all issued acts – for this, the commercial director can go to the card, add a field and enter a simple formula for it.
• Low-code is the filling. This layer is often the whole point. With its help, you can set up those unique rules, processes 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 is more than 1 million rubles and the counterparty is new, then the approval process should go along the branch with the participation of the financial director." Or the analyst sets up a more complex chain of the sequence in which the stages of product release in production should take place, starting from procurement and ending with delivery and logistics, taking into account the setting of access rights to the information needed at this stage, the role model and the conditions for completing tasks.
• Code (for developers) is the classic biscuit of this layered masterpiece. It is worth mentioning right away: it is not always there. 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 legacy or write a new unique service, then this layer is laid as a 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 write this module, "pack" it as a simple block and give it to analysts for use in the low-code layer.

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

An additional, but critically important aspect – the cherry on the cake, 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, see the change history and roll back the process to yesterday’s stable version with one button. This is insurance against anarchy. And for complex and branched configurations, 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 quickly can we create something?” to the question “how can we create quickly, but at the same time build a manageable and durable digital asset?” The answer lies in the plane of synergy: organizational changes (like creating a competence center) must be based on the right technological foundation. A strategy without instrumental implementation is just a declaration of intent. And a scattering of even powerful tools without a single strategy is a direct path to “patchwork” automation and technological chaos, which everyone is so eager to escape from.

Only the fusion of a full-fledged strategy and a suitable tool forms the supporting structure on which the entire digital evolution of the company will be based, where speed ceases to be an antagonist of reliability, and innovations are organically woven into the fabric of corporate architecture.

That is why the choice of a platform solution becomes not just important, but decisive. It should not be a box with disparate constructors, but a holistic environment, which is essentially an "industrial sandbox": it gives the business creative freedom, but leaves it in a safe contour outlined by the IT department.

Such a platform becomes an organic part of the existing IT landscape, not breaking 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 an investment not in immediate automation, but in the operating system of your digital transformation itself – a springboard from which the company can take quick and confident steps into the future.