No-Code and Low-Code Apps: Look Before You Leap

Gartner predicts that by 2025, 70% of the applications that companies develop will be either low-code or no-code, and why wouldn’t companies move to these methodologies? Low and no code applications place app development power directly into the hands of end users, who no longer have to wait for IT to be available.  

It’s easy to generate these apps, too. With a no-code application generator, all you have to do is to point and click at the resources and operations you want to include, put in your rules, and you’re done. 

Low- and no-code application generators have a long history. They were originally known as 3GL and 4GL report generators, which for decades gave users (and IT) simplistic ways to quickly generate reports that didn’t require complicated logic and integrations with underlying IT infrastructure. 

Hitting the Wall 

Like their 3GL and 4GL ancestors, no- and low-code apps are quickly developed and deployed. They also share one important limitation with 3GLs/4GLs: They require IT's intervention when enhancements are needed for interoperability with IT infrastructure.  

This is one of the reasons why no- and low-code apps very well could follow in the footsteps of their 3GL and 4GL predecessors. They are great for a while, but after a time their helpfulness gets overcome by the need for enhancements and greater IT integration. Then, they get put on the shelf. 

Related:How to Build a Team of Talented Citizen Developers

How does this happen? Here is an example: 

A retail chain’s finance department develops a no-code report that tells them that the company is losing money because too many items are being returned. Unfortunately, all this report tells finance is that there is a problem. Root cause analysis can go no further than to tell them that for some reason, returns are inordinately high. 

Finance then wonders, “Can the root causes be found by understanding operational failures in manufacturing, or imperfect components that are being sourced by purchasing from third parties?” 

There is no way to know this unless item-level warehouse returns, vendor parts performance histories, manufacturing performance, etc., can be viewed alongside the data that finance already has. This can’t happen unless finance’s original no-code report is integrated with other corporate systems that contain manufacturing, purchasing, warehousing and possibly even product engineering information. 

Managing Low- and No-Code Apps 

Since companies and their data are highly interrelated, when applications are enhanced to do more, they need to touch other systems. That's a job IT must do. 

Related:How CIOs Can Grease the Wheels for Citizen Development

It is at this stage that a low- or no-code app enters the IT maintenance and enhancement queue so it can be modified, integrated, and performance tested. This is also the point where the users lose control over the development and deployment of their applications. 

Users don’t like losing application control and IT doesn’t particularly want to add new applications to its enhancement and maintenance load. So, what can be done to manage it? 

One way is to set guidelines across the enterprise for the best use of low- and no-code applications. 

The first step is stipulating application limits. 

If users of no- and low-code apps understand up front that whatever they develop will have little or no opportunity to expand beyond what their toolset can do, they will know what the limits are and just how far they can enhance their work. One line that could be drawn is to establish with users that a no-code app’s enhancement potential will go as far as they are able to develop the app without IT involvement. In many respects this is already what users understand when they develop an Excel spreadsheet, so there is precedent for treating no-code development in the same way. 

A second step is to set guidelines and guardrails for no- and low-code development. For example, if a user in finance wants visibility across multiple enterprise systems, internal guidelines can inform him or her that multiple system integration and integration with underlying IT infrastructure will require IT involvement, even if a no- or low-code tool is used. 

Related:Working With Non-IT Users Who Do IT

The value of users knowing this up front is that they won’t pursue a no- or low-code app project on their own if it has no chance of giving them the level of interoperability that they will ultimately want. 

End of Life Considerations 

Deciding when to discard a no- or low-code app also is an important topic. 

It matters because no- and low-code apps are so new that few companies have contemplated non-use and end-of-life issues. However, like their traditional IT application counterparts, no- and low-code apps also can arrive at points where they are seldom or never used. 

For this reason, it’s a best practice for IT to get together with end users so that application non-use guidelines can be defined and agreed to. If, for example, a no-code app goes unused for two years, should it be discarded or at least offloaded to low-cost storage? 

These housekeeping practices can be established so non-used apps don’t idle away storage, processing and other IT assets.  

Summary Remarks 

No- and low-code applications offer enormous opportunities for companies to get more IT work done faster. They also empower users. 

Therefore, the goal for CIOs right now is to set the parameters for no- and low-code development and maintenance, so that the best possible outcomes from such work can be achieved, with users getting as much autonomy as possible to develop their apps.  

By regularly meeting with users to see what types of applications they have in mind, and what are the likely enhancement roadmaps for these apps, IT and end users can determine whether a low- or no-code development effort is the best fit.