Low-code - faster design and implementation of applications and IT systems.

Low-code appears to be a long-awaited and optimal solution for entrepreneurs, because it enables them to directly participate in the design and implementation of the solution they have created. Thus, the canon of business support tools is enlarged by another innovative category of solutions.

What is Low-Code?

If you want to find low-code publications online, you will most often come across those that describe low-code software as well as LCDP (Low Code Digital Platform). Those are tools that use an entirely new way of programming. Low-code programming. It literally means programming of a given IT solution with a small amount of code.

However, this explanation may not be understandable enough, so juxtaposing it with the traditional way of software development will make it clear.
 

Standard programming

The creation of a website, dedicated application, or IT system begins when the client accepts the mock-up or prototype of the project. First, a work schedule is planned, and then software engineers and a dedicated team of programmers move in.

One of the early stages of programming is writing of the source code. If we want for instance a simple contact form to be created, the developer has to write code describing each element of the form. The code also includes information (inserted online or extracted from an external file) about formatting such a form, including:

• its dimensions, colours, frames,
• how the text will be displayed (font, size, colour, style, spacing),
• how it will be placed compared to other elements, e.g. headers or margins of the website.

We see the prepared form as end-users. But there is more to be programmed:

• types of fields and method of processing their content,
• rules determining the correctness of the entered data,
• additional action buttons (e.g. attach a file, send),
• relations between them.

In the case of a field, a developer programs the way in which it should be completed and what will happen when these conditions will not be met by a person completing the form.

Examples of form field programming rules:

• compulsory fields are symbolically marked with "*",
• the field for entering the e-mail address should always contain the "@" symbol, 
• similarly, while trying to change the password - in this field, the programmer has already defined the minimum number of characters and what special characters it should contain or which are not allowed. After these conditions are met, we will have to change them - otherwise, we will receive an error message,
• GDPR fields that the user marks to agree to the processing of personal data for a specified purpose.

Formatting of the form discussed is a semi-automatic process. The programmer does not have to write the entire source code but can insert a ready component (e.g. a table). In turn, to implement a given function, he can use the console, which will tell him what part of the code to enter.

Despite these amenities, the implementation process is still time-consuming, especially in the case of more complex applications or systems. The same applies to integrating systems from different sellers. It is then required to program a special API (Application Programming Interface) connector.

An additional obstacle is also the lack of a sufficient number of programmers on the IT market in relation to the current demand.
 

Low-code programming

The goal of low-code is to reduce programming and conceptual time and at the same time move from the design phase to implementing a digital solution.

One of the biggest advantages of this solution is the fact that from the very beginning we are designers, even if we do not have programming knowledge, or skills.

We have a graphical user interface (UI) at our disposal, such as for example in graphic programs or even in popular CMSs.

From the panel, we select the appropriate components that will be part of the project we are creating. For example, it will require the creation of e.g. a holiday request to be filled in. We use ready-made templates located in the user panel, e.g. in the form of a dynamic form, and modify them according to our needs.

Using the interface, we design the appearance of the application, change the color of the form, font, and add new fields. At first glance, this is similar to form-building tools, but there is an initial difference. Each of the form fields can be 'programmed' just like a programmer writing the source code, but in a more intuitive way - by selecting a text field and marking the appropriate function from the drop-down list.

Request programming examples:

• defining a mandatory field - we usually 'program' by selecting e.g. YES / NO for the function, which is equivalent to the developer inserting required in the source code. 
• adding an attachment, specifying the file type and its weight. It is similar here - we can check whether we want to allow the end-user to add a file, its type (PDF, docx), and size, e.g. up to 20MB.
• inserting of a field, e.g. the reason for the complaint, and adding from the drop-down list that will allow one or more options to be marked.

In addition to the possibility of creating forms, the platforms also have BPM (Business Process Management) / Workflow tools for managing and planning processes and workflows. Because of them, it is possible to easily draw a given process, dependencies between all its elements, and define conditions affecting the process.

Companies often use these tools when planning their systems so that the implementation company has a complete picture of how the processes in the organization work and connect. To do this, you first need to define the main phases of your process and then place them as elements on the diagram.

Sample phases of a simple process based on the complaint request:

• filling in and sending the complaint form by the Customer:
• receiving of the request, its classification, and recording in the system (assigning a reference number),
• automatic e-mail confirmation about the acceptance of the request,
• verification of the request, and decision making,
• feedback to the customer (result of the complaint).

At the very beginning, it will be just a static diagram with major phases. Then we move on to programming a holistic business logic and dependencies between elements in the diagram - we design the workflow.

We give them the direction of flow, we define what conditions should be met in order to be able to proceed to the next phases, and what should happen when moving to the next phase.

For this purpose, we use a special section in the user panel, which has predefined functions - actions that will be performed after meeting or not fulfilling certain conditions.

Examples of actions and dependencies:

1. Filling in the request by the client:

• positive verification: the client has correctly completed the request, added an attachment in the appropriate format, the "Send" button is active.
• negative verification e.g. the Customer did not choose the reason for the complaint, an appropriate message is displayed with a request to fully complete the request.

2. Records of the application sent by the Customer in the system:

• classification and initial record of the application: assigned to the appropriate category on the basis of the selected reason for the complaint, the number of the request is given.
• verification of the content of the request and an attempt to automatically solve the problem on the basis of the existing, ready-to-use solutions

3. Forwarding the request for further circulation:

• the request is forwarded to the appropriate department,
• at the time of assigning the verifier, the notification status is assigned,
• an e-mail is sent to the customer with the status and traceability.

These are just a few simple examples of business logic available as low-code. However, it may happen that we do not find the necessary action. Then we can point to a given diagram element to display the hidden source code and modify it so that it is possible to perform the given function.