Maintaining Low-Code Apps When The Citizen Developer Moves On

Maintaining Low-Code Apps When The Citizen Developer Moves On

Maintaining Low-Code Apps When The Citizen Developer Moves On

The explosion of Citizen Development is a really good thing for business and a welcome relief to the IT department. It means there’s no clog in the pipeline for the feature requests operations needs to do business. But what happens when the Citizen Developer moves on to another department or another company? Who takes over? Does the app just die?

One thing’s for sure. At some point in time the people who create today’s apps are going to move on to somewhere else. If that’s a place inside your company, it will make it easier for you to maintain continuity of the app — at least temporarily. But if they leave the company entirely, it could cause a big void.

The best thing you can do is plan for that day by setting up standard guidelines and policies for the Citizen Developers who do the work. It’s important to remember that a lot of low-code development was born from frustration with company bureaucracies that took forever to get things done, so making it easy for them to adhere to guidelines and policies should be your number one priority.

Here are three ideas.

  1. Require basic documentation for each app.

This doesn’t have to be complicated, but it can take you a long way in preparing for the day when something needs to be done and the original app creator is nowhere to be found. Create a simple form to capture basic information about the app and keep it in a central repository. You could even create an app or another table in your app to keep track of this information. Basic information to capture should include:

  • The original intent of the app. Why was it created? What was being used before the app was created?
  • What was the app a solution for? What problem did it solve?
  • Who were the key stakeholders and users that were included in the app development? It’s good to know people’s names so you can tap into them in the future if needed.
  • How the app is structured. If possible, create a relationship diagram that shows the relationship between data, entities, and attributes. Some low-code platforms like QuickBase already have this built in for you.
  1. Require a backup person for each app.

This is just good business. Have at least one backup person who has basic knowledge of each app who can step in if something happens to the key app builder. Don’t allow “lone wolves” who can put your business at risk.

  1. Conduct a regular Citizen Developers roundtable.

Once a month or once a quarter, get all the Citizen Developers together and talk about what’s going on. This will keep everyone in the loop about what’s happening and can help keep duplication of effort to a minimum. It will also give them a resource for bouncing ideas off one another and create a valuable knowledge asset for your company.

This should take your company a long way in protecting your business, but what do you do if your company has a bunch of apps and no original app builders?

Your best bet is to take a look at all of the existing apps and spend some time doing an assessment. Here are some questions you should ask:

  • Is the app still needed?
  • Does the app still solve the problem?
  • Are people using the app?

If the answer is yes to all of those questions, have someone interview the current stakeholders of the app to find out how it’s being used and whether it’s still efficient in resolving the problem it was intended to solve. Find a way to document the app’s structure and place the information gathered in the central repository. QuickBase has some good information on this in the following eBook and on the QuickBase Blog you can find here.

The people closest to the problems are the best at solving them. Learn how to enable employees to create their own task-driven applications to get more work done.

Citizen Development Playbook

Related Posts

Posted in Citizen Development, Rapid Application Development | Tagged , ,

Comments