by Betsy Burton

One of the advantages of being in this industry for a number of years is that you get to see some common themes recycle. One of the themes that has recycled more recently is the concept of low/no-code application development.

The last few months, I have received several briefings on low/no-code application development platforms (LCDP). And it is great to see that many of them are really easy to use to develop a basic productivity application quickly. In addition, however, it is important to understand their strengths and limitations.

Recurring Theme       

It is important to pay attention to emerging technologies and how we can use them to support technology-enabled business operations and new business models. It is also important to know the history, so we can weigh the costs and benefits of adopting.

How many of you remember 4GLs from the mid- to late-1980s? They were application development tools that were connected to a DBMS that provided a user interface that could be customized without writing a significant amount of code...at first. The more complex the application, the more customization and development code was required. Companies like Information Builders, Cognos, Unify, and Computer Associates built their businesses on 4GLs.

In the early to late 1990s, products like Borland Paradox, FoxBASE, Microsoft Access, and Ashton-Tate dBase supported application development tools connected to a lightweight DBMS (relational or flat-file). These tools were largely targeted to power business users who could develop some applications. Once an application became more complex, however, more coding was typically required. Some of the early scripting languages became a critical part of these development tools.

A new generation of web/internet-based development languages and tools gained more popularity and supplanted some of these easy-to-use development tools.

Benefits of Low/No-Code

We are seeing a new generation of LCDPs emerge, and many are quite similar to some of the development tools from the mid-1990s in terms of ease of use and development.

One big difference is that these tools are often offered foremost as a service, rather than a product; supported within common cloud services, including Amazon, Google and Microsoft Azure.

In addition, these services are being developed using a platform architecture, which can make integration and extensibility more straightforward. As a result, these services can offer more connecters, particularly developed by partners and citizen developers.

Last, they support common and full function RDBMSs rather than flat-file databases, including Oracle and MS SQL server, as well as common integration hubs. And many vendors, such as Salesorce.com and Microsoft, support application capabilities, such as CRM, that can be extended.

Issues With Low-Code

The biggest challenges with LCDPs are largely related to management and governance. LCDPs are typically targeted and marketed to power-users in business and IT. The messaging from many of these vendors, including Microsoft and Salesforce, is that these are applications developed by citizen developers that are then brought to IT management.

The advantage of this approach is that the vendors can grow a grass-roots base of developers to advocate for their adoption. The challenge with this approach for companies is that they could find themselves in a position of having tens, if not hundreds of little applications developed by citizen developers that are not driven by a strategic approach, are potentially inconsistent, and are likely not integrated.

This growth of citizen development can quickly introduce significant governance, management, and application/data integrity issues. Speaking of history, I remember speaking with a client several years ago who discovered they had well over 100 Access applications that took years to reconcile.

I am not suggesting business or IT management try to stop citizen developers from using these tools. However, it is more critical than ever that organizations define a strategic business-driven approach to using LCDPs, and ensure that they are part of an overall governance strategy and performance management effort.

Bottom Line

LCDPs will certainly grow over the next years. And, as power users and businesses demand more capabilities from these applications, they few will require more custom code and extension.

IT leaders and CIOs must not ignore this development or brush it aside as “rogue” or “shadow” IT. Citizen and business use of these tools should be supported as a valid part of the organization’s technology-enabled business, and must be managed as such.

Technology and service providers must understand the background and history of these development tools. They must understand and track how user need for additional development capabilities, including code, will also evolve over time.