Citizen Developers & ITAM – a Low Code cautionary tale

SAM

Citizen Developers & ITAM – a Low Code cautionary tale

At the recent ITAM Review Wisdom EMEA 2023 conference, a question was raised regarding ITAM’s role in managing citizen development / low code – something which was identified as a growing trend. From my perspective gained from over 25 years in IT Ops roles I found it interesting that this issue has come back to the fore, as I’d experienced many times in the past. For ITAM teams – which are tasked with managing IT assets – low code / citizen development poses a dilemma. Whilst we currently focus on off-the-shelf solutions and software from publishers, should we or do we have responsibility for managing and protecting the IP of internally developed code?

What is citizen development?

Citizen development can be broadly defined as non-developers creating applications and services to aid personal productivity, provide tactical solutions to business requirements, and potentially even provide a solution which is a significant revenue stream. In some ways this is similar to Shadow IT – and to a certain extent is made possible by the ready availability of development tools and platforms via SaaS, in particular the growing number of Low Code / No Code platforms out there.  

In a traditional IT department, it’s generally the case that there’s a formal relationship with in-house developers. For example, they may have dedicated development licenses and environments, managed by themselves and somewhat outside the direct control of IT. They’ll almost certainly have enhanced rights – such as the ability to download and install software – compared to standard end users.

Hopefully the ITAM team is aware of who they are and have appropriate processes in place to manage the license compliance risk dev teams incur. With so many publishers having developer-specific license terms it’s certainly important to have good trustworthy data about what your developers are doing.

The problem arises when development takes place outside formal development teams. There are a range of issues beyond ITAM risk in this including privacy, security, and code hygiene which I won’t cover in detail in this article. The discussions at Wisdom raised two risks from low code / citizen development that ITAM teams should be aware of.

1.     Unclear commercial rights, especially with open-source software

Most developers make heavy use of open-source code in projects, and this poses a significant risk in terms of managing intellectual property (IP). This depends on the license terms for those libraries. Until recently the primary risk was being obliged to open-source proprietary code developed using open-source libraries with strong copyleft terms. Such terms allow use of open-source libraries but only if the resulting work (or combination) is also open sourced. Clearly this would significantly impact revenue if you were seeking to sell such software.

However, in recent years, new risks have emerged. Open-source libraries and projects previously made available for free for commercial use are tightening terms which require payment of a license fee for such use. For a number of years there have been grumbles from the open-source community about Amazon’s extensive use of open source in AWS. Only recently has Amazon policy changed to become more of a “good citizen” in terms of commitments by its employees to the projects they profit from. Of course, AWS is a scale of usage unto itself, but such tactics are also being applied to smaller entities. In fact, it could be argued that Oracle’s changes to Java licensing are one such example. The impact is that organizations relying on free commercial use of open source in their products could suddenly be faced with a license charge for commercial use. An attendee at the conference noted that they had seen an increase in these tactics and behaviors from open-source providers this year.

Why is this important in the context of citizen development? Well, in the case mentioned above, the organization had tight control over its formal development community so all that was required was that they were notified of the license change and the financial impact could then be determined. But what if there is widespread citizen development? It’s often difficult to discover open-source usage unless you know where to look and in some cases who to speak to – if your tools can’t discover it then asking your devs what they’re using may be the only way to find it. Clearly that’s not something you can do if you don’t know who your citizen developers are. If this trend of open-source providers restricting commercial use continues alongside an increase in citizen development, there’s potential for significant risk to arise in ITAM from low code / citizen developers. What’s the solution?

The solution

Above we noted that, as with shadow IT, it can be difficult to control risks associated with citizen development due to difficulties in discovering deployment and usage. In the absence of tooling the best defense may be to develop policies and best practices regarding citizen development. Alongside the policies it may also be vital that risks are communicated to potential developers. An awareness campaign along the lines of those run by IT Security on topics such as phishing may be required.

2.     Becoming reliant on citizen-developed tools: A cautionary tale

It can be easy to see this as a somewhat theoretical risk. Maybe you don’t use open source. Maybe you don’t have development teams. The reality is that this has been an issue for many years, as illustrated by this cautionary tale.

One of the first readily available development tools for non-developers was Microsoft Access. A graphical relational database with forms support which meant something resembling an application could be developed by anyone. Front end, back end, code, even export and import functions. Access also shipped with runtime support, meaning your application could be compiled and run by anyone with the free runtime installed, no full Access license required.

In this period every organization I worked for eventually developed a policy to restrict who had Access installed and what it could be used for. Why? Primarily because the applications developed didn’t follow development standards, were insecure, and often difficult to maintain and support. In one organization I worked for a citizen-developed application was used daily by hundreds of users. This application was revenue-supporting, helping generate millions of dollars per year. It was utterly vital to business operations and developed by an employee in marketing with, it must be said, pretty impressive development skills. All was fine for several years until that employee left the organization, taking the source code with him. All we were left with was the runtime with no way to reverse-engineer it to add new features or provide support should something go irrevocably wrong.

The app was so important to the business it became the Holy Grail which simply had to be supported regardless of impacts on other systems or working practices. For its users it became increasingly flaky and a source of stress as it was vital in meeting daily deadlines and revenue targets. We even went so far as to have emergency on-call cover for the application because we were a 24/7 operation. Over the years we slowly painted ourselves into a corner with this application until eventually it broke and required replacement. That replacement took time to develop during which time revenue was impacted and targets were missed.

This happened due to citizen development, poor governance, and fear of breaking an application which was vital to the business. Not a small business either – a FTSE100 company which had ample development and governance resources at its disposal.

Summary

The risks of citizen development are clear and appear to be increasing as open-source projects target revenue from their commercial users. Furthermore, the age of the API, no-code, AI, and readily available SaaS-based development tools mean that there is a much greater pool of potential citizen developers in our organizations. By creating awareness around the issue along with governance standards ITAM teams can ensure that innovation takes place safely and support key stakeholders such as architects and CTOs.

Can’t find what you’re looking for?