5 Key Practices - What IT Takes to be a Citizen Developer on Low Code Platforms?

Does the IT department and the applications development team have to own and lead all application development efforts?

Over my last couple of posts, I've been exploring how Citizen Developers - developers using light weight, often low code development platforms can help their business functions automate tasks, analyze data, develop knowledge repositories, and connect data across applications. As a CIO, I've developed citizen development programs and believe it may be the next big thing in application development, but it takes some discipline and defined practices to avoid the potential perils of citizen developed applications.

So in this post, I'll share some practices that will make these programs successful. Keep in mind that what you elect to implement from these practices will likely depend on the goals, strategy of the program and technical capabilities of the platforms selected. So for example, using IFTTT SaaS platforms like Zapier, IFTTT, or itDuzzit to connect SaaS data platforms may not need a lot of rigor, but self-service BI programs need lifecycle practices and IT provided data management services. It also helps to understand technical bounds, so low code platforms like QuickBase, Tableau, QlikSense, may be in scope for Citizen Development while others offering more technical capabilities like Force.com still require IT ownership or participation.   

 

 

What Practices Are Needed To Enable Citizen Developers?

There are several ingredients needed for citizen development to flourish.

• CIO sponsorship of these programs is critical, otherwise IT will view the platform and applications developed by citizen developers as rogue IT. There is also a greater risk of citizen developed data silos or other unsupportable applications. CIOs that are not on board may communicate that these programs are contributing to enterprise data landfills or creating new data governance challenges. The last thing organizations need is a divide between IT and organizations that want more technology and are willing to roll up their sleeves to get it. Note, I should also point out that organizations selling low-code platforms should invest more effort selling and partnering with the CIO!


• Formally define and communicate a strategy, list of example opportunities, and target platforms so that the organization can align on a selected approach and priorities. What you don't want is every department pursuing different platforms, or that the program is only successful with a handful of early adopting departments, or that citizen developers create applications that add more complexity than value.  


• Establish the development practices and lifecycle for applications developed in these programs. Is there a review committee to determine priorities and appropriateness of platform? How are versions maintained? What naming conventions and documentation is minimally required? What UX/UI standards will be leveraged in these programs? How are applications tested? What security is required and reviewed? How are these applications monitored and how are end users support provided when required? When and how does the organization recognize that they've outgrown an application and a more scalable solution required? Who and how is it decided when venturing into coding practices, data integration, or API usage permissible?


• Who are the acknowledged Citizen Developers? What skills are required to be part of the programs? How do you get their managers engaged and supporting the program? What training, mentorship, and rewards is provided to successful developers? How are best practice on developing applications shared with other developers?


• How are you marketing, promoting, and providing access to successfully developed applications? Where is the directory to find these applications? How are access roles and other permissions defined so there is consistency? Who signs off on new user access? Who is solicited on priorities for enhancements? Who takes responsibility for rolling out and communicating changes to end users? 

This doesn't need to be overwhelming or hard and it doesn't need to be defined all up front. It also doesn't require all the rigor required of a software development lifecycle. This is just a sample of considerations and what to think about as a citizen development program is kicked off or  matured.