Let’s demystify low-code

0
8

It’s time to clear up the misconceptions about low-code and take full advantage of its benefits to accelerate the digital transformation of our companies!

In a world where everything always has to go faster, where users want to be more and more autonomous out of agility and flexibility, the promises of low-code platforms sound positive. However, professional developers tend to mock these tools and platforms for reasons that may have been genuine in the past, but deserve an update and a pinch of objectivity! So let’s try to demystify the use of such platforms and put an end to some persistent prejudices. Certainly a bit heavy task that I will try to take on.

Enterprise Class application

I’ve often heard: “Low code is not made for setting up critical applications”, “It’s very good for modeling, but no more”, “We need to deliver web desktop and native mobile!”.

If we can hear these comments for no-code platforms, I completely disagree with low-code platforms whose playing field is really critical, innovative and why not customer-facing applications. The customer cases should speak for themselves and show the range of possibilities and the variety of possible applications, regardless of the functional areas (HR, finance, business, industrial applications, etc.), the type of applications (innovative, modernization history, operational efficiency or digitization of UX) or usage (web desktop, native or hybrid mobile – PWA).

Low-code tools also make it possible to tailor applications to integrate them into an existing application and respond to tangible constraints, without sacrificing implementation speed benefits.

Technically, low-code platforms do not impose anything and integration with existing building blocks is offered, both organizationally and in terms of governance or security. On the other hand, they offer native tools for customers who are not or partially equipped (source manager, build manager, project follow-up). This is to stay as close as possible to the strong constraints that can be imposed by the customers, to be part of standard DevOps practices and to enable a chain of integration and continuous delivery.

Technical possibilities and speed of delivery

“I can’t do exactly what I want”, “I get limited and constrained” and “I built myself a dev framework that allows me to be really fast”.

We cannot deny that a low-code platform will impose a framework, but they show openness with the ability to call services of any type at any time, inject server or client code, create extensions for integrations or for presentation … we will therefore never be limited. So if I have to permanently inject code, I definitely lose interest in such a platform… but honestly, in many years of experience, I have never faced such a need from a client.

Suppose I need to inject code into each of my application’s pages. A low-code platform will (and should) allow me to easily create a page template that embeds this need so that I can industrialize it and reuse it in my next projects without having to go through the hassle again… object-oriented programming is therefore again in force and expanded within such a platform.

In terms of speed of implementation, if you started developing an acceleration framework, it’s because you’re in a low-code dynamic. Low-code platforms have the advantage of having more history and R&D, so chances are they’re a few steps ahead of you. And at first glance, a professional developer will also tend to underestimate the load associated with many additional features that are part of an application (functional management interfaces, management of traces, permissions, reminders, etc.).

Data management

“I have no control over my data”. Sensitive and critical topic for low-code tools in SaaS mode and that deserves clarification. The question does not arise when the platform or applications are deployed on-premise. However, regardless of the method of deployment, a low-code tool will always offer the choice in the system that will store the company data.

By default, the company data is hosted within the database that underlies the operation of the platform (and therefore online), but thanks to the various connectors, the designer can decide to outsource this recording to data management of which you are the full administrator. This can be done through web services if your system makes them available or through DBMS connectors through direct SQL integrations. For governance purposes, the design tool will provide graphical visualizations of the connections and usage of the various resources.

From an application architecture point of view, if you don’t want to multiply data management systems and take advantage of this storage space included with the platform, the data in this underlying database is natively encrypted at rest and in transit; and for hypersensitive data, the designer can even apply their own encryption keys before storing.

Let’s also not forget that a low-code platform must leave the intellectual property of applications and data to its customers and thus provide them with tools to extract them whenever they want.

Reversibility and supplier loyalty

“Once I set foot on the low-code platform, I’m stuck and can’t change it.” Let’s be realistic, we cannot deny that there is some truth to this statement, but it needs to be nuanced. A good low-code platform must offer exit options to its customer, and this can be done on several levels.

First, the need for reversibility is not always linked to the tool itself, but perhaps to the application hosting. An organization may feel the need to migrate everything hosted in one public cloud to another. A low-code, cloud-native platform is inherently ready for that and will transition very easily due to its containerized architecture.

Then of course it can be a question of changing the tool, in this case such a platform should provide tools that allow to extract the models, classes and data in order to be able to import them again in another tool. Nor is it magic, the developments found will certainly require a phase of understanding and probably adjustment, but it has the merit of being made available.

However, let’s not forget that the challenge of reversibility is not linked to low-code platforms, that is the case for everything, and I’m not just talking about tools. An application developed with a framework that is several years old, when it is entitled to refactoring…. Chances are that the development team prefers to start from scratch, from a technical point of view I hear (because the functional knowledge continues to be acquired, which also applies to low-code platforms).

No more IT services needed

“With low-code, IT services are no longer useless, what am I going to do?”

The objection here is different because we know the value and importance of a low-code platform, but if we no longer need to be a professional developer to build enterprise applications, what are they going to do?

First of all, it is important to note that IT services retain all their importance. Their skills will be needed for the most technical parts of an application (integration with a new tool, creation of an extension, etc.). This allows them to concentrate on tasks of high technical importance.

Then the trend moves to the exponential growth of business needs and their permanent evolution. By allowing less experienced designers to participate in the creation of business applications and accelerate delivery, it also eliminates bottlenecks in IT resources.

Finally, let’s not forget that these platforms allow teams with different profiles to communicate within the same universe. So this makes it possible to streamline exchanges, to get closer to a common language… and the reconciliation between business and IT is invaluable.

Conclusion

What if low-code wasn’t just a new development standard? The young history of programming languages ​​has been the birthplace of many (r)evolutions, from the punch card to object language, via binary, assembly and procedural languages… low-code or graphical programming n wouldn’t that be the next step? The arguments for moving from one of these evolutions to the other have always been: stronger abstraction, easier understanding, more accessible environments, democratization of the development process and improvement of implementation speed… Do you notice that? We absolutely love it with low code.

Similar Posts:

LEAVE A REPLY

Please enter your comment!
Please enter your name here