8 tips for managing low-code citizen developers

The central tenet of low-code and no-code tools — that business users can be leaned on to fill the ‘app gap’ — is resonating with enterprises.

According to Gartner, 41% of non-IT employees build or customize their own solutions — and by 2023 these “citizen developers” will outnumber professional developers fourfold in large enterprises, the research firm predicts. Most organizations already use at least one low-code tool, adopted by departments or individual users with a problem to solve. One day, perhaps soon, developing apps without writing code will become as common a business skill as email and spreadsheets, Forrester predicts.

But with the benefit of faster development come greater risks. Governance over the increased autonomy that self-service and low code bring has become a key IT consideration, according to Gartner.

While formal governance structures aren’t yet common, IT leaders are starting to tackle the issue of managing low code. “They know they want to empower many, many people to do technology work, and they want to do it in a semi-orderly way,” John Bratincevic, a senior analyst at Forrester, tells CIO.com.

Low-code platforms bring improved productivity, cost savings, and often a culture change that improves relationships between the business and IT. Done right, low code can help organizations achieve the kind of continuous improvement that business transformation has always promised, with a culture of digital problem-solving.

Here’s how CIOs can help citizen developers be successful in a pragmatic way that mitigates risks without discouraging experimentation and self-service.

Move out of the shadows

For low code to succeed, IT leaders can’t address it as shadow IT, and it shouldn’t be viewed by CIOs as a potential burden, says Gartner distinguished VP analyst Jason Wong.

“The purpose of citizen development is to say we have an agreement between IT and the business, the participation and input of these citizen developers into what they want to build, and understanding what tools are best for them,” he says.

Moreover, low-code and no-code platforms don’t just provide a way to build apps visually: They also centralize access and resources and track how they’re used. Because of this, IT can create policies about who will have access to what data sources and how they’re allowed to share apps and automation flows that incorporate that data.

Granular role-based access control enables IT to manage access to specific endpoints and data tables, down to the field and record level, giving the appropriate access to different departments on different development environments. You should also be able to manage what connectors are available and which actions they can take on an endpoint. For example, you might want customer support to be able to build apps that can read but not post tweets, or you might decide globally to allow low-code users to update records but never delete anything.

Balance control and autonomy

Getting the right balance of control and autonomy for citizen developers is critical. You don’t want poor security, but if governance and access processes are too onerous, people will just go back to ungoverned shadow IT.

That will take planning, Bratincevic notes. “It’s not super complex but you got to think it all through and it’s specific to your environment,” he says, adding that before you can set up governance, data is key. “The foundation of that is: What data do we have and what is sensitive and what isn’t.”

Be sure to apply data leak protection to any data shared externally, and to have policies that warn citizen developers if they’re creating an automation or workflow that might violate compliance — for example, copying email or PII.

Citizen developers should also have autonomy on platform choice. It’s a mistake to force the business to standardize on a single low-code platform, Wong cautions. If business users don’t have the authority to pick tools that work for them, you don’t have citizen development.

Instead, rely on your governance framework and make it clear how much support those users can expect if they choose a different tool, Wong says. “Here’s the scope of what we can do; here’s the safe zone. If you want to co-create here are the things we can co-create and support,” he adds by way of example, “but don’t expect IT to train up resources to understand this specific tool to build the components and widgets in that platform; we just don’t have the bandwidth.”

Pick the right strategic approach

Establishing the right strategic model for your organization’s citizen development issue is also key.  

Forrester identifies three common approaches, the first of which is a small, autonomous team made up of people with process improvement experience, approved by IT but embedded in a business unit and reporting to a business executive. This strategic approach is very agile but won’t scale, Bratincevic says: “Obviously, it’s a small team doing all the work.”

The second approach is self-service, in which anybody can develop with low-code tools based on policies and guardrails in the platforms. “You’re controlling the what, instead of the who,” Bratincevic says.  “Who is anybody, but the what is constrained by the nature of the platform and the data access you give them.”

The third, most mature approach combines agile teams and broad democratization into a federated model, with a center of excellence managing low-code platforms, implementing guardrails, and supporting teams or individual champions in departments and business units as well as self-service low-code developers.

In this model, how a specific app is developed depends on its use case, the data used, and the experience of the developer involved, Bratincevic explains. “You might have more or less steps in the security development lifecycle; you might have more or less requirements around previews; you might have to work with somebody before using a certain data source.”

This mature model is more complex “but it’s also the one that covers the most ground: You’re controlling the data, controlling the development process but being pragmatic about it,” he says.

Provide adequate IT support

In addition to governance and policies, CIOs need to provide resources and support. “The attitudes of IT towards citizen developers is incredibly important towards their productivity and their successful outcomes,” Gartner’s Wong says.

To do so, Gartner suggests formalizing citizen development with a governance framework that covers “green” safe zones, where citizen developers can create workflows and automation; “yellow” support zones, where citizen developers work with professional developers to build more powerful applications; and “red” danger zones that require IT oversight and approval, with some apps considered so complex and business critical they remain under IT control.

A center of excellence, for example, might create APIs and custom components or enable fusion teams with pro developers who work in both low-code and traditional development environments. The COE might also provide learning resources and expert help for citizen developers for more complex or critical work such as writing query expressions, perhaps with open office hours.

This kind of collaboration and support is what differentiates low code from shadow IT.

“With shadow IT, you have individuals off on their own, doing stuff that’s in the shadows, out of sight,” Wong says. “Citizen development says, Let’s open this up so that users don’t fear being reprimanded for using these tools. We have a path for them to learn as they need to: They just want to go deep enough to build what they need and learn as they go, with the ability to ask for help from the community, from other power users, but also potentially from IT.”

Get APIs and connectors right

To succeed, IT needs to be proactive about making connectors available and creating robust APIs for access to internal data.

“Make sure your APIs are well defined, have a management layer or catalog, and then are easily connected to by these low-code/no-code solutions,” says Kin Lane, chief evangelist at Postman, an API platform.

You also need to track where APIs are used in production, both to keep a handle on costs for external APIs and to make sure the systems that deliver an internal API are resourced appropriately. Not everything that works like an API is produced by a robust back end. “As much as we’d like to believe that a well-designed RESTful API is what constitutes an API; that’s just not true,” Lane notes. “An FTP location with a CSV is considered an API, and spreadsheets are king.”

And don’t forget about robotic process automation (RPA), an increasingly popular way for getting information out of legacy systems and into low-code apps and automation workflows. By establishing an RPA workflow that automates the extraction of data from scanned PDFs, for example, IT can further empower citizen developers to create beneficial business apps.

Don’t forget reviews and metrics

Individual business users who are solving their own problem are unlikely to think about high availability, business metrics, or any kind of formal reviews. Few low-code platforms include tools for that, but metrics such as the time it takes to complete a process can be helpful, as can introducing regular reviews to track performance and analyze opportunities for further development.

Metrics and reviews also provide opportunities to examine businesses processes, as automating a bad process just gets you bad results more quickly. Use process mining tools to uncover inefficiencies or extra work some teams may be performing, and give the staff who actually work on a process opportunities to streamline it instead of just creating apps that slap a bandaid over the problem.

Evolve operations as necessary

Analytics and monitoring tools in low-code platforms can not only track API usage but also alert you to apps that have become so popular or business-critical that you might want to move them to the higher-tier yellow or red support zones, outlined by Gartner.

Ground-breaking ideas that turn into apps that are so popular that they need more IT support are a sign of business innovation, Wong says. IT’s job is to make that sustainable.

In practice, this progression can create tension; the original low-code developer may have concerns about IT taking over the tool, and the IT team may have concerns about supporting an app they didn’t create or specify. A culture of collaboration between business and IT should help avoid suspicions on both sides.

Foster a culture of innovation

While you may worry that low-code experimentation will produce too many apps for your IT team to cope with, a more common problem is not gathering enough momentum to make the strategy work. Many business users with problems that low code might help them solve won’t naturally think of themselves as “developers,” Bratincevic points out.

“There are a lot of technically minded businesspeople doing technical work or shadow IT,” he says, but “even the people who are doing that work won’t necessarily want to buy into a formal program with a governance platform.”

Many organizations find internal hackathons — with time for training, mentoring, and support — can kick-start interest and generate a core of initial apps. Alternatively, look for problem-solvers who might thrive as early adopters. People who are already using shadow IT as part of a role that involves continuous improvement or special projects are prime candidates to become champions, especially if they’ve requested an app that IT hasn’t had time to start working on.

Low code can enable significant career progression, with business and front-line workers gaining expertise for more technical roles. Think of it as a way of growing your future digital workforce — and be prepared to support and reward staff to achieve that. One reason low-code programs fail to scale is the expectation that employees will work on it in addition to their day jobs rather than as part of that, especially if company culture doesn’t value continuous improvement.

You also have to deal with the human aspect of change management. What if the original citizen developer moves on to another job and their colleagues or replacement aren’t interested in taking the app on? Or, if they are interested, has the app’s purpose and background been adequately documented to be handed over?

On the other hand, not every low-code app will stay useful for ever, Wong says. “If no one steps up to own it then the assumption has to be: It wasn’t very useful; let it die.” That’s less of a problem when the cost of implementation is so low in the first place.

Think of low code as an opportunity but also realize it’s inevitable, suggests Bratincevic.

“It’s not going to be perfect; there are going to be problems, you are going to make some mistakes, but this is your opportunity to orchestrate all the people developing apps across the organization in a way that’s connected and automated and sensible; to set up the right foundation, as opposed to leaving it all to chance.”