Evolving Citizen Development to Meet AppDev Demand
Well-built business applications can streamline virtually any business process. We know this. It's not controversial.
As business units seek to improve efficiency and meet customer expectations, the demand for new applications has increased to a level far exceeding the resources available to produce them. This, too, is not controversial.
What can be confounding, and occasionally controversial, are the options many organizations have turned to as they seek to close the widening application gap—in particular, citizen development.
Closing the App Gap
Traditionally, app development has been the purview of IT departments and was led by professional developers steeped in software development, design, implementation, and tools. But the truth is that there simply aren't enough skilled developers in the workforce—a problem we've faced for years that is only getting worse. Moreover, the increasing need for greater business agility and better customer experience has made digital transformation a priority for enterprises. These factors have exacerbated the problems of the gap between app supply and app demand.
Seeing an opportunity to close this gap, some companies adopted new technologies that made it possible for non-IT professionals (citizen developers) to create business applications quickly and at low cost—at least in theory. Aided by these low-code tools that abstract and automate much of the traditional application development process, companies have tried to ramp up their ability to churn out software by giving users the power to assemble applications for general use.
In theory, citizen development seems like a great approach because it expands the number of people available to build applications. The other appeal to it is that it eliminates the need to explain requirements to professional developers; the people and teams that will use a solution are the people who build it, so there's no translation for something to get lost in.
In theory.
Citizen-Development Doldrums
Citizen development became fashionable at the end of the early aughts, so we've had just over 10 years of experience to observe its efficacy. More often than not, it appears to lead to considerable chaos—albeit with the occasional genuinely wonderful result. For companies increasingly putting every expenditure of money and time under a microscope, the hope of occasional success is simply no longer good enough.
To be clear, citizen development occasionally works out rather nicely. Far more often, however, it creates additional challenges for organizations. Even in the best of circumstances (to wit, a successful citizen-created application), an aspiring citizen developer inevitably devotes less time to their nominal job and more time to pet projects; this can create a bottleneck in other areas of the business. Another common byproduct of successful citizen development involves citizen developers realizing that they enjoy application building more than they enjoy their original role, resulting in a wave of career changes. This can be extremely disruptive and costly for companies that have to hire someone to fill now-vacant roles.
And when it doesn't work out rather nicely, why? Well, while non-IT employees may have a more accurate understanding of the purpose of the app in question, they don't often think like developers in creating the app. Unless they have specific training in things such as UI principles, data and process modeling, systems integration, compliance, reporting, support and training, etc., the likely result will be that they create an unsupportable application that brings benefit to them individually but inflicts harm on the larger organization.
That's right, harm. This could be something as obvious as a diversion of resources to repair, speed up, or enhance an application—taking time and money away from other priorities. But a lot of mistakes are made with citizen-development projects—often in the areas everyone finds boring and tedious: security, privacy, data integrity, exception handling, compliance, documentation, and so on. These areas may be boring and tedious, but they are critically necessary.
Anarchic approaches, even when good in and of themselves, can create harm at scale. Imagine a scenario in which five people in different departments build five applications that look and feel five different ways. If the same people use multiple applications, that means five different training efforts, lots of cognitive context-switching on a day-to-day basis, and an often well-after-the-fact realization that the applications need to be integrated with each other somehow.
Collaboration, not Abdication
Ceding technical innovation to nontechnical people might not have been a good idea after all. Allowing employees to divert time from their regular tasks to work on their own applications is a risky proposition at best. We've effectively been asking non-IT employees to become mini-IT managers, which is a pretty tall order even when time and money aren't tight.
But the conditions that made citizen development attractive remain very real. There is a talent gap. There is a communication gap. Can these be addressed without the "bypass IT" approach inherent in most citizen-development efforts?
The answer is yes. Let's start with ways to close the communication gap.
What citizens have going for them is a keen understanding of the problem and the need. To date, we've asked them to either (a) do nothing but ask for things and wait, or (b) do everything on their own. What about having them be part of a project? With the right tools and training, the people closest to the business need are uniquely poised to act as citizen designers. As such, they can own the "what"—whereas IT-directed developers can be responsible for construction, owning the "how."
Non-developers have had over a decade to become better at knowing what's possible, even if they might not be masters of execution. They are now in a better position to tell IT what they want in ways that IT will understand much more clearly. If they are armed with tools that guide the process of specifications and acceptance criteria, all the better. Less decoding, exploration, and negotiation will need to take place—and developers will have instructions that are immediately actionable.
Making citizens take on a design role—participating rather than asking for things and then waiting—has real potential. It's also not a completely new idea. In some circles, this is called "citizen-assisted development"—in others, fusion teams. Moreover, since the design phase of a classic project can take as long as the construction phase, working on improving design is very much worth our time; reducing design time speeds up projects.
Low-code tools and platforms therefore remain a key part of the solution—but most low-code tools focus solely on the construction phase. They need to be optimized for productivity beyond just construction. (A learning curve is okay provided there is a reward for it.) We also need low-code packaging and deployment, documentation, change management, compliance, privacy, security, metrics, monitoring, auditing, and more.
We could argue the exact percentages, but let's assume for a moment that one-third of a project is design, one-third is construction, and one-third is delivery. Low-code tools that don't address the entire solution lifecycle are missing the point—and helping a lot less than their marketing people claim.
As for the talent gap, there remains real value in looking beyond traditional coders for help—but maybe we should still demand some expertise. Low-code tools in the hands of professionals can yield rapid results without a loss of solution quality. With low-code tools, people who aren't coders but still possess technical talent can still extend the talent pool.
Moving Forward
We entered 2023 witnessing companies already cutting back budgets and looking for ways to do more with existing assets. Nothing suggests that this trend will change any time soon. Companies regard uncertainty as expensive—often rightly so. It's time to take a hard look at the 10-year experiment with citizen development and adapt accordingly. By taking the best of professional development and citizen development and melding them into something new, we can reduce risk and produce better results. Whether it's called citizen-assisted development, fusion-team development, or collaborative development, it's worth adopting.