The utility and popularity of the development tools commonly called no-code or low-code solutions is clear. Such tools can be summarized as point and click graphical development environments, which provide an easy to use route to application development for business users rather than professional developers. With the growing popularity of these tools, we see the retirement of the business "power user" in favor of a new term — the "citizen developer." The term appears to have captured the popular imagination although I don't personally see its use.

Whatever we call it, this is a distinctive movement with obvious business benefit and value and many vendors competing in the space. One of my favorite industry analysts, Dion Hinchcliffe, recently said that the use of such tools is key to organization's broader digital transformation efforts, as there are simply not enough professional developers available to do all the work.

Vendors Competing in the Low-Code/No-Code Space

I don’t have much need to develop apps in my own work, but I have played with Microsoft's Power Automate, one well-known example of this kind of tool. An example of the flexibility of Power Automate is the ‘connector’ we built for it. This connector abstracts over 50 API calls to the point where a business user can create an app via a point and click interface which allows them to build workspaces in our document management platform, add documents to them, set the permissions in them and take so many other actions. It is a little mind boggling to be honest. Many of the other vendors in the space also have marketplaces with prebuilt connectors to abstract and simply access to their APIs.

Creating an exhaustive list of the available tools is beyond the scope of this article, but a few of the well-known and popular no code / low code tools include:

As we can see even from this short list, vendors range from specialists that originated in this space like Appian, to well-known names like Microsoft, IBM and Tibco. This means it's likely there's an offering that works the way you want or need it to, that meets your budget and the needs of your business users, and that fits well with your enterprise IT environment.

It's fair to say I am an enthusiastic proponent of business power users being given the tools and capabilities to solve business problems themselves.

Related Article: Is Low-Code Technology Right for You?

Is There a Downside to the Citizen Developer Approach?

Are there any potential risks that could take the shine off this approach? Yes, but they're pretty easy to deal with if we acknowledge them and find ways to manage them in a suitably easy and agile fashion.

The risks could in fact be many and varied, and potentially include all those normally considered as part of software development. They will depend on what your organization is, what industries and markets you address with your products. They will also depend on the overall approach you take to business unit no-code / low-code development. Does the enterprise IT function know about and support your approach to developing your own business solutions, or are you doing this on your own for speed or budget reasons, or perhaps because there is actually no governance framework within which you can operate?

Learning Opportunities

There may be little intrinsic business risk or information governance risk involved in simple apps that enable a simple business process, provided they do not work on business critical information. At the other end of the spectrum, can you be sure that the figures being pulled from some back end data store, added to a spreadsheet which is work-flowed to various stakeholders for review and approval are the latest, verified values? Is that spreadsheet going to be used for forecasting? Did anyone check the business logic embedded in your app?

Related Article: The Evolution of the SharePoint Citizen Developer

A No-Code / Low-Code Development Governance Framework

Ideally you'll have an organizational policy and framework in place for governance of app development. It should be straightforward and address the risks and controls put in place to manage them. Write the policy in clear, easy to understand language so business unit colleagues can follow it — filling it with IT jargon will defeat the purpose. It must clearly state what is considered a suitable approach to no-code / low-code development by business units, and should be very clear if any prohibitions are in place (e.g. if your app meets certain criteria, it must be developed, tested and deployed by IT). 

The policy should address the following elements:

  • The business objectives — what problem is this app / solution going to solve, what efficiencies will it create?
  • What tools / platform do you intend to use?
  • Who will own the application and be responsible for it?
  • What inputs will it consume and what outputs will it create?
  • What is the business logic encapsulated in the app or workflow?
  • Who created the app, and who tested it?

Following a simple set of rules and documenting your process doesn't need to be onerous nor does it need to be heavyweight. QA and testing should be on a sliding scale depending on how critical the app is and the information it is working with. It can range from having a second set of eyes in the business unit review the business logic and final app, to a process for submitting the design and final app to IT for review and approval. The whole point is to balance risk against managerial process. We don't want to negate all the advantages of truly agile creation of business solutions by the people closest to the problem, but we do want to make sure it's done in a safe way that protects the organization as a whole.

As with all elements of information governance and IT risk management, it’s all about balance.

fa-solid fa-hand-paper Learn how you can join our contributor community.