Today, low code/no code (LC/NC) applications are getting more and more popular. The reasons are they can provide a close fit to business requirements, can be implemented quickly, and typically cost much less than systems developed in-house. These applications don’t accomplish these benefits by magic, they turn over development to users instead of professional system developers. With point-and-click or pull-down menu interfaces, users can usually design and implement their individual or departmental systems in a few hours. The software may also have a conversational or search interface. Few, if any, programming skills are required.
RPA is one of the fastest-growing categories of LC/NC systems. Using rules for simple decision-making, it allows users to design automated workflows that can reach multiple information systems. This is excellent for automating back-office administrative processes. Some RPA tools offer advanced features that aid the discovery of automation opportunities or connectors to AI tools to create what some now call “intelligent” or “augmented” automation. RPA would generally be classified as low-code, but there are “light” versions of the software that are no-code, which are closer to “plug and play” but offer fewer options for customization and scalability.
However, there are not only great benefits from LC/NC software development but management challenges as well. Broad use of these tools institutionalizes the “shadow IT” phenomenon, which has bedeviled IT organizations for decades — and could make the problem much worse, if not governed properly. Citizen developers tend to create applications that don’t work or scale well, and then they try to turn them over to IT. Or the person may leave the company, and no one knows how to change or support the system they developed.
LC/NC oversight can control this issue, however, and make common the handoff of applications from citizen developers to professional ones when appropriate. IT organizations need to maintain some control over system development, including the selection of which LC/NC tools the organization will support. The best situation may often be a hybrid citizen/professional development model, in which the user develops 80% of the model, and hands it off to the developer for polishing. Or the user may develop the initial application using a graphic interface tool, and then give it to a developer to program it in Python or some other more scalable language. In either case, the developer can record that the system exists, ensure that it works correctly, and connect it to any needed data or transactional system. We’ve seen organizations where one system developer supports ten or more citizen developers.
The bulk of the responsibility for managing LC/NC development, however, will fall on department managers, since most of the resulting systems are at that level. Department managers should be encouraged to facilitate LC/NC development, and be educated about how the technology works, what tools the organization supports, and the desired relationship between citizen developers and the IT organization. They should also educate their department members on the opportunities and responsibilities of LC/NC development.
Department leaders and the executive champions, too, may need to become more educated about the best practices for scaling LC/NC tools, especially across large geographical footprints. New organizational models such as a federated COE (Center of Excellence) may need to be created, supported by internal digital portals (or “storefronts”) where citizen developers, system developers, and leaders can collaborate, and learn, and quickly get help when encountering roadblocks. As LC/NC systems scale and create their own datasets around business processes, further investments in supporting analytics and infrastructure might be needed to aid governance.
Almost every organization today needs more system development talent. LC/NC development isn’t a panacea, but it can address some of these resource shortages. Over time, it’s likely that systems will become even easier to build for common processes and use cases. As Chris Wanstrath, the former CEO of code-sharing repository Github, put it, “The future of coding is no coding at all.”
