Application development has traditionally been the domain of the IT department. The development of an application usually requires specific skills such as being able to translate a business problem into a programmed solution or understanding the structure and use of data in a database. Because of this expertise the business user depends on the IT department. The result is quite often the same: an IT-project running over time and budget resulting into a solution that leaves most users dissatisfied.

The introduction of low-code and no-code platforms such as Mendix and OutSystems delivers on a promise that was already made quite some years ago, which is the ability to develop IT solutions without having to be able to translate your solution into a program – software that writes the software. A low/no-code platform enables you to create an app by just dragging and dropping and clicking it together. Define the data you want to store, let your app use this data and you are done. The app runs in a public or private cloud so no need to manage how it is distributed or maintained. The app can be used on a mobile device, a workstation or even in a web browser.

This also has another major consequence. The developer no longer needs to be part of the IT department. Any tech savvy business user can develop, distribute and run a solution for his or her business problem. No more dependency on the IT department. This introduces the notion of the citizen developer. A non-IT person with IT affinity that is driven to create in a matter of days the IT solutions the business really needs.

Is this a good thing? Basically, the answer is yes. IT really needs people that can bridge the gap between the functional and the technical. Instead of having to translate a business problem into written requirements that are incomplete and prone to misinterpretation, the citizen developer can create an actual working solution to solve the exact problem he or she is facing. Besides that, how useful will it be if IT can be relieved of the development of “simple” quick win solutions it will never get around to delivering due to other obligations.

Of course there is a “but”. Most IT solutions are not standalone entities. They are part of a larger landscape and as such need to fit into that landscape. An important task of the IT department is to maintain a vision of what the IT landscape looks like – i.e. what entities define the landscape and how these are related – and what the landscape should look like – i.e. what the current and future development of these entities is. A regular business quickly uses thousands of IT solutions, ranging from a simple text editor to business-critical systems with all the apparent and not so apparent interfaces between them.

Now imagine what will happen if citizen developers start creating all kinds of apps outside the view of the IT department. Soon a number of these apps will contain information or functionality that is already stored in or performed by other apps or even core systems. Or apps will contain information the company needs to be aware of – think GDPR. We need to avoid the situation where a plethora of standalone solutions is created without any control over what information is stored and processed where. Compare this situation to the one we had a couple of years ago when every department decided to setup its own SharePoint solution with a lot of standalone information silos as a result.

So even if part of the development effort shifts from the IT department to the business, the IT department still needs to maintain the responsibility for the IT landscape and all the solutions that make up this landscape. Does this mean that the citizen developer should be on the leash of the IT department? Not at all, we must welcome all involvement of the business in the development of their own IT solutions. But we must also create a new paradigm that both embraces and structures this cooperation between the business and the IT department so that low/no-code solutions become an added value to the IT landscape and not a “been there, done that” thing we once did in the past.