Citizen Development: The shaky bridge between business & IT

Citizen Developers can shorten software development turnaround times aggressively. That is, if we go about it the right way. The Citizen way-of-working holds many promises, like connecting business and IT for real. But for most, it is a high bridge with steep ramps. This article explains the Citizen Development phenomenon, the advantages, its link to low-code and no-code development and extends two recommendations to avoid common pitfalls at implementation. There is a special responsibility for architects. 

WHAT ARE CITIZEN DEVELOPERS?  

Typically, “citizen developers” are business users with little or no coding experience building applications with approved IT technology. Business users building their own solutions is nothing new, people have been building solutions using spreadsheets and database tools for years. The difference is that IT, instead of actively developing software, is monitoring the development of software while sanctioning and documenting any new functionality. Broadly spoken, IT offers a “self-help” option while safeguarding technical, security and architectural standards.   

WHAT IS “SHADOW IT”?  

Basically, citizen developers are primarily business people, and they are interested in helping the company to drive new business outcomes using IT. Business and IT, in fact, are all on the same team here. From an IT point of view, you can think of citizen developers as non-IT, or even external to the company. Consequently, IT is no longer completely in charge of software evolution. This is where the term “shadow-IT” stems from, and it predates the emergence of Citizen Development. With shadow-IT it seems as if there is a second department that, however informal, also delivers IT services. However, nobody takes advantage of this rather negative hum of the term “shadow-IT”. An enterprise architect, standing on the bridge between business and IT, should actively challenge and discourage its use and instead point to the potential synergy of business and IT. Citizen development is all about close collaboration between both departments, opening new ways to accelerate the smaller changes in application development. This is where low-code and no-code platforms come in.  

WHAT IS LOW-CODE DEVELOPMENT?  

Especially low-code application development is fast gaining popularity. That’s good news because it is a genuine revolution in business software. It ensures that business applications can be delivered much faster with a minimum of manual programming and minimal investment in training and implementation. However, low-code platforms come in all shapes and sizes. And that is exactly where the shoe pinches. The selected platform affects the IT service, and architecture in particular. Architects should therefore be at the forefront in platform selections and define the short- and long-term impact on the architectural roadmap. How does it change the capability framework? Exactly for what architectural purpose do you use this or that variant?  

Broadly speaking, low-code application platforms come in two categories (low code and no-code), and both offer a solution to the same problem: the slow delivery speed of business applications. With a low-code platform, programming work is kept to a minimum and a lot of functionality no longer needs to be developed from the start. In addition, low-code applications can always be easily changed, in contrast to a software package or custom software. When low-code software development came into vogue, the platforms available were mostly suited for creating simple web apps with limited functionality. However, the low-code landscape has grown considerably in the meantime. There are many more different platforms available, and the depth in terms of possibilities and areas of application has increased significantly.  

WHAT ARE NO-CODE APPS?  

In the low-code landscape, no-code development is the lightest variant. No code is often introduced by the business in response to a as rigid perceived IT department, and usually without further consultation. The available development platforms are mainly aimed at end users within organizations with little or no technical knowledge, who want to make their business applications more accessible via a visual (web-based) environment. These end users take on the role of “citizen developers”. In practice, no-code is bought by the business and used for small applications with limited functionality, for example to handle maintenance work, or to realize certain additional possibilities that are not offered in a large software package. No-code development is accessible and can quickly add value, but please note that both the functional possibilities and integration with other applications are limited.   

WHAT ARE LOW-CODE APPS?  

A slightly heavier category than no-code consists of low-code app platforms. Low-code is often used as part of the strategy to unlock the legacy systems, sometimes driven by the business and in other cases by the IT department. Low-code platforms are also intended for citizen developers, who can have a business or an IT background. Developing with a low-code app platform is less visual and slightly more technical, requiring more training. But the possibilities are much broader than with no-code development, as are the possibilities for integration with other business applications. However, the resulting low-code applications remain apps. Above all, they offer a great way to bring information and functions from various other applications together in one integrated app. Low-code apps are therefore often used, for example, to fill functional gaps in large software packages or to develop business dashboards.   

AVOIDING PITFALLS EMBEDDING A “CITIZEN” APPROACH  

To avoid one common pitfall, it is key to understand the variants, limits, and implications of introducing low-code platforms. In that, there is a special role for architecture. Any “citizen capability” should be regarded as a new asset to the architectural framework and embedded as such. Safely setting up a “citizen option” requires a bi-modal approach: rather than being set up by one party, it is effectively a brand-new deal between business and IT, tapping into and aligning several processes of both. Enterprise architecture can be instrumental here.  

A natural reflex is just adding the “citizen option” to (agile) workflows, creating a process part where “Business meets IT”. However, aligning and managing processes of two often antagonist domains is as hard as it is likely to fail, since they traditionally serve different purposes and objectives. Instead of tweaking existing workflows to accommodate citizen development, the governance of any citizen working practice needs to be built from the ground up. It is more than adapting a DevOps or embedded IT way of working, where IT submerges in the business. In the citizen world, business may churn out pieces of software, while IT is in general still accountable for them.  

Another threat to the successful introduction of citizen development is reserving too little time for its implementation. As always, it is key to start with the end in mind by asking “what question is citizen development the answer to?”. Capturing the perceived issues and linking them to available “citizen solutions” will strengthen the business case to define and facilitate the platform selection.  From an architectural point of view, the impact of citizen development on the existing landscape, as well as on its roadmap and governance should be thoroughly analysed before any decision is taken on adapting citizen development. For enterprise architects, its governance (risks, planning, integration, sourcing) is an add-on to the portfolio of architecture services. 

In short, citizen development can revolutionize IT delivery, as it is a genuinely new ingredient of the relationship between business and IT. It accelerates software development and enables the business to quickly react to new insights and market trends. If implemented properly, it also helps standardizing architectural building blocks (SBB’s and ABB’s). However, those attractive advantages come with the risk of insufficiently realizing the fit of a platform for the organisation (limitations) and failing to understand that the implementation and the required culture change will be done in a nick of time, or happen by themselves.