How to secure Citizen (Low Code) Development — Part 2: Stakeholder perspectives
In the second post of my series on “How to secure citizen (low code) development” I’d like to focus on the different stakeholders, their perspectives and requirements when it comes to securing citizen development efforts.
Since the first post of this series (How to secure Citizen (Low Code) Development — Part 1: Why is it different?) established the differences between “regular” software development and citizen development activities, we will use these differences to identify the stakeholder groups and their perspectives.
Typical stakeholders of Citizen Development activities
Most of the differences and unaddressed requirements fall into one (or more) of 4 different stakeholder groups and their perspectives:
- Cybersecurity
- Enterprise Architecture Management
- Operations
- (Citizen) Developers
Cybersecurity represents the perspective that requires all development activities of an organization to follow cybersecurity policies, guidelines and best practices. This perspective comprises of all requirements related to cybersecurity from governance (e.g. defining and assigning ownership of an application) to operation of an application and requirements such as security logging and Identity & Access Management integration.
Enterprise Architecture Management (EAM) covers a wide variety of activities, processes and requirements when it comes to software and citizen development. In the scope of this post, its perspective represents the requirements of a business that govern and guide all development efforts of the organization to ensure that software and enterprise architecture(s) align with the business strategy and that development activities create and leverage synergies instead of duplicating efforts and diverting from architecture guidelines. An example of a requirement from the EAM perspective is to design, implement and use well-defined APIs and resilience patterns such as message queues between services or applications.
The Operations perspective represents the needs and requirements of the part of the organization that is in charge of “keeping the application running” and maintaining the application(s) once the development activities are concluded. While I’m aware that this is not how DevOps works, I’d like to point out that I have yet to see an organization with a textbook implementation of DevOps, especially when it comes to citizen development activities — since most citizen developers develop applications to improve their personal or business units productivity and do not plan to become full-time developers. Typical requirements of this perspective include “abilities to administer the application”, “different log levels for troubleshooting purposes” or the ask for extensive documentation.
Last but not least there is the perspective of the Citizen Developers themselves. The goal of most citizen developers is to quickly build something that is improving their personal or business units productivity. This perspective requires streamlined processes to request access to development resources and as few management approvals and quality gates as possible. A common expectation of citizen developers is to be able to build, deploy and share an application with their team within a couple of days to a week.
Summary
All of the above stakeholder groups and their perspectives have to be considered when trying to secure citizen development activities, as these groups usually base their requirements on business strategy, laws or industry regulation and common best practices. I would even argue that it is unlikely to achieve a sustainable level of security in citizen development activities without taking these requirements into account when setting up the security program for citizen developers.
In the next post of this series, we will use the perspectives of these stakeholder groups to identify activities and deliverables within a typical Software Development Lifecycle (SDLC) that can be used to fulfill the respective requirements while introducing as little friction for citizen developers as possible. The goal of this approach is to enable citizen developers to innovate at speed, securely and sustainably.
If you liked this post and would like to learn more about the approach I’m going to propose in my later posts of this series consider following me on Medium, as I will release posts every week.
