Participatory Budgeting (PB) puts a part of a city's public budget directly in the responsibility of its constituents - most notably, the citizens - who can make proposals on how to spend the money and vote on the proposals they like best. This type of resource allocation can increase democratic understanding and the efficiency of public spending. However, integrating or adding such IT-supported PB applications into eGovernment systems is far from a trivial task as a PB should not be isolated from the rest of the governmental IT systems but integrated. Thus, the complex system landscapes of the municipalities have to be touched. Reference architectures can guide the creation of future-proof software. Hence this paper is meant to assist the implementation of PB into an existing eGovernment landscape by proposing a PB reference architecture. It shall support administrations who plan to implement a PB by proposing a possible system architecture and integration scenarios. As PB is part of an eGovernment system, it also presents a state-of-the-art eGovernment IT architecture on which other applications can build.
Participatory Budgeting (PB) puts a part of the public budget directly in the hands of the constituents.
The citizens can craft proposals for spending the budget, which are later voted on by the community,
with the proposals receiving the most votes getting implemented. This democratic process of allocating
parts of the budget increases the inclusion of otherwise overlooked groups, triggers debates on how to
spend the budget, increases the public’s understanding of governmental processes, and thus strengthens
the quality of democracy. Further, PB improves state performance by increasing accountability [
In recent years, the idea of PB spread worldwide and increasingly took hold in administrations
worldwide. Moreover, as PB initiatives often use specialized software ([
While some research papers describe actual instantiations of eGov-architectures, neither a general reference architecture for PB nor eGov systems are available. This lack leaves aspiring administrations in need of such systems on their own. Even though their needs and challenges are often similar, every administration needs to create its own IT architecture, which leads to unnecessary heterogeneity and
2020 Copyright for this paper by its authors. costs. Our research aims to fill this gap. This paper’s goal is to derive a technical reference architecture for these PB applications into a broader governmental IT landscape. At first, we identified already existing PB initiatives and gathered the state-of-the-art in eGovernment architectures based on a systematic literature analysis. In the next step, the core features of a PB were integrated into a universal service-oriented eGov architecture. While the current focus of the architecture is on participatory systems, we believe that the architecture can also be used to integrate other kinds of eGov systems.
A systematic literature analysis first gathered the current state-of-the-art. The analysis is grounded in
the methodology for systematic literature reviews in information systems research proposed by Barbara
Kitchenham [
The identified architectures differentiate the core elements like user interfaces, application servers, or
data storage. While some research, like [
The first layer (Access Layer) of the eGov reference architecture concerns access to governmental
services. It addresses the various devices that the end-users utilize. While [
The next layer manages the access control through Authentication and Authorization. It builds upon
the single sign-on (SSO) proposed by [
The layer Service Bus comprises the business logic of the eGov system. As seen in the literature
analysis, most of the more recent eGov architectures ( [
As a result, the PB software in our architecture is just one of many applications that utilize the same
interfaces as the other eGov applications. Our architecture depicts an archetypical PB process based on
[
As already stated, PB initiatives differ widely depending on the jurisdictional and cultural
backgrounds. The instantiation of the application of the PB process is, thus, always bound to local
customization. A detailed description of possible functions along the exemplary process of such a
system is given in [
The Data Layer is the gateway for accessing the databases and storing the documents needed for the
applications to fulfill their tasks. The layer is proposed by [
The Infrastructure Layer is responsible for provisioning the computational resources and
networking infrastructure of the services. The papers upon this reference architecture is built regard this
layer as the provision of servers, networks, data centers, hardware, and more [
The proposed infrastructure layer is based on the NIST definition for cloud computing [
There are three service models regarding the cloud virtualization level: In a Software as a Service (SaaS) model, the organization orders the whole software from a provider and pays per use (e.g., per active user). The provider takes care of the provisioning, licensing, and updating of the services. Even though some applications can also be installed in a private cloud and managed through a provider, these services normally run off-premise. The provider handles everything except the installed software in a Platform as a Service (PaaS) model. The managed services include the operating system, runtime environments, and servers. In an Infrastructure as a Service model (IaaS), the provider handles the servers, networks, and virtualization infrastructure. Here, the consumer controls everything from the operating system to the application. However, eGov applications can also run On-Premise without a cloud virtualization infrastructure. Please note that the decision for or against running the infrastructure in the cloud is not binary. It is also possible to run just specific, new applications on this virtualization infrastructure. Most likely, some SaaS application is already in use, like Microsoft Office 365 or Zoom.
Managing complex IT architectures is a tedious and complex task, as many systems with many interfaces need to interact and share data. Without structuring, these systems can uncontrollably grow out of control, making them costly and hard to maintain. Reference architectures can support the structuring tasks by providing blueprints. This report presented a reference architecture based on existing literature for integrating a PB application into an eGov landscape. It is targeted at administrations who plan to implement a PB initiative. The reference architecture shall enable these administrations to (1) assess their current eGov architecture, (2) identify the technologies needed to create a PB, (3) identify possible integrations for a PB application into the existing landscape, and (4) adapt the proposed reference architecture to their individual needs.
Even though the systematic literature analysis of this paper ensures that the built reference architecture is based on the already existing body of knowledge, it is not yet validated in practice. Thus, future research directions should be concerned with validating the proposed reference architecture in real-life examples.
The authors are part of the EU-funded EmPaci project (Empowering Participatory Budgeting in the Baltic Sea Region). This project is part of the European Regional Development Fund.