openspp.orgArchitecture
Contents
Architecture#
Principles#
OpenSPP must follow platform based approach so that all common features can be configured or the functionality can be extended by other parties.
OpenSPP must not use proprietary or commercial license frameworks. Where deemed essential, such components must be encapsulated to enable their replacement if necessary (to avoid vendor lock-in)
OpenSPP must use open standards whenever possible to expose its functionality (to avoid technology lock-in)
OpenSPP must use commodity computing hardware & software to build the platform
OpenSPP must be simple to deploy and use
OpenSPP must be able to work for small projects with few thousand beneficiaries up to large ones with tens of millions of beneficiaries
Data must be encrypted in-flight and at-rest. All requests must be authenticated and authorized. Privacy of Identity Data is an absolute must in OpenSPP
OpenSPP must follow the following manageability principles:
Auditability & monitor ability of every action in the system
Testability of every feature of the platform
Easy upgrade ability of the platform
OpenSPP should work with different locales so that that social protection systems can be localized for languages and cultures easily
The key sub-systems of OpenSPP should be designed for extensibility. For example, if an external system has to be integrated for entitlement determination, it should be easy to do so
Ecosystem approach#
The OpenSPP platform can work as a standalone system or as a part of a larger ecosystem. It needs to be interoperable with other government systems.
Every piece of information stored in the platform must have a corresponding API to access it, so that it can be used by other systems. For example, if you want to integrate OpenSPP with mobile money, you can leverage Payment Hub EE. Through a well-defined set of standard interfaces OpenSPP allows for integration of such components and offers choice of providers for the same.
So, key parameters are:
All public/external facing interfaces of OpenSPP must be standards-based for interoperability whenever possible.
3rd party components should be integrated via well-defined interfaces and be easily installable.
Configurability#
OpenSPP should be flexible for countries/organizations to configure the base platform according to their specific requirements. Some of the examples of configurability are:
Be able to choose the features required.
Be able to configure the attributes of the beneficiaries.
Be able to define the criteria used to determine the beneficiaries.
Be able to define how entitlement is calculated
Extensibility#
OpenSPP should be flexible to extend functionality on top of the basic platform. Some of the examples of extensibility are:
Modularity#
All components of OpenSPP should be extensible and their features exposed via interfaces such that the implementation behind the interface can be changed without affecting other modules. Some examples of modularity are:
Determination of eligibility to a program
Calculation of entitlement
deduplication of beneficiaries
High-level Functional Reference Architecture#
The OpenSPP functional architecture diagram above presents an overview of the components and layers of a typical OpenSPP implementation.
Data Layer
The Data Layer is responsible for storing and managing the data generated by and used within the OpenSPP system. It consists of the following:
Database: The database stores structured data, such as program information, beneficiary records, and transaction data. It uses a relational database management system (RDBMS) such as PostgreSQL.
Object Storage: Object Storage is a component that stores unstructured data, such as images, documents, or other multimedia files. Currently, file storage has been used.
Data Access Layer/Odoo ORM
The layer simplifies data interaction through object-oriented constructs and offers CRUD operations, querying, and filtering.
Odoo Core Functions
Oddo is an existing, open-source ERP (Enterprise Resource Planning) system that is used as the foundational layer to build Open G2P and OpenSPP platforms.
Open G2P Core Functions
The Open G2P (Government-to-Person) Core Functions represent the central components of the OpenSPP system which are used to build OpenSPP functions.
Functional Layer
The Functional Layer of OpenSPP consists of various modules that implement the functionality which is required in a social protection program. These modules can be tailored to specific program requirements, and additional features can be added based on the requirements identified.
User Engagement Layer
The User Engagement Layer contains the user interfaces (UI) for interacting with the OpenSPP platform. This layer includes web applications and mobile applications.
Stakeholders Layer
Stakeholders are the various parties involved in implementing, operating, and evaluating social protection programs. They include government agencies, non-governmental organizations, private sector partners, and the beneficiaries themselves.
Integration Layer
The Integration Layer connects the OpenSPP system with external systems, such as national identification systems like MOSIP, payments like Mojaloop, and other data sources/systems. This layer allows the platform to exchange information and interoperate with other relevant systems.
Non-functional requirements
Non-functional requirements are the characteristics of the OpenSPP platform that are not directly related to its functionality but enable the platform to be reliable and robust. These include security, privacy, audibility, monitoring, performance, scalability, availability, and maintainability. Only a couple of non-functional requirements are shown in the diagram.
High-level Deployment Reference Architecture#
The on-premises deployment of OpenSPP encompasses a suite of interconnected components, each playing a vital role in delivering secure, robust, and highly efficient service. This document is intended to provide an high-level understanding of the OpenSPP on-premises deployment architecture and its key components.
A. The components description#
Firewall
Serving as the entry point, the Firewall regulates the inbound and outbound network traffic based on predetermined security rules. It protects the system’s integrity by preventing unauthorized access and mitigating potential security threats.
Application Load Balancer
The Load Balancer optimizes the performance of OpenSPP application servers by evenly distributing the incoming network traffic across multiple servers. This not only enhances resource utilization and throughput but also prevents server overload. The presence of active and passive nodes ensures failover protection and high availability.
Identity Server
The Identity Server effectively manages user identities and controls access to resources. It employs advanced features such as single sign-on, access delegation, and identity federation to ensure secure and compliant access to system resources.
API Manager
The API Manager in OpenSPP manages and secures APIs, controls access, and collects usage analytics. Acting as a gateway, it validates and routes API calls, manages request rates, and supports API versioning. It's instrumental in enhancing system security and optimizing service quality.
OpenSPP Application Servers
These servers form the nucleus of the OpenSPP system. They execute the OpenSPP application and coordinate with databases and the API Gateway. The use of active and passive nodes guarantees continuous service and failover protection.
Database Load Balancer
The Database Load Balancer facilitates the efficient distribution of database queries across various instances. This ensures optimal resource usage and high availability of database services.
Databases
Databases serve as the data storage centers of the system. They interact directly with the application servers and are crucial for OpenSPP's functioning. Given the large volume of data handled by OpenSPP, a scalable and highly available database system is indispensable.
Caching Databases
Caching Databases enhances system performance by temporarily storing frequently accessed data. This reduces the strain on primary databases and expedites data retrieval processes.
Object Storage
This component caters to storing unstructured data such as files. Its high scalability makes it an ideal solution for storing large data volumes.
File Storage
File Storage manages the storage of structured data in a hierarchical file system. It handles files such as documents and spreadsheets.
Email Gateway
The Email Gateway is tasked with managing email communications in a secure and efficient manner. It plays a pivotal role in sending and receiving emails within the system.
SMS Gateway
The SMS Gateway allows the system to send and receive SMS messages, ensuring a seamless channel for alerts, notifications, and two-factor authentication.
Monitoring and Alerting System
This component vigilantly monitors the health and performance of the system. It promptly issues alerts for any detected anomalies or performance issues, ensuring rapid response and resolution.
Log Aggregation
The Log Aggregation component centralizes log data collection from all system components. It is a critical tool for analyzing system behavior, aiding in diagnosing and troubleshooting issues.
Understanding the OpenSPP on-premises deployment architecture and its components is essential for effective system management and maintenance. This architecture, focusing on performance, scalability, and fault tolerance, provides a comprehensive solution for the on-premises deployment of OpenSPP.
B. The specification of the components#
Below are the recommended server specifications for each OpenSPP on-premises deployment architecture component. Please note that these specifications might need adjustments based on the specific needs of the deployment of the country/organization, such as the number of users, the amount of data, and the desired performance.
Component |
Recommended Technology |
Specifications |
|---|---|---|
Firewall |
Preferred Hardware Firewall or pfSense |
CPU: 4 cores |
Load Balancer for Application Servers |
Nginx, HAProxy, Keepavalied |
CPU: 4 cores |
Identity Server |
Keyclock |
CPU: 4 cores |
API Manager |
Apache APISIX |
CPU: 4 cores |
OpenSPP Application Servers |
- |
CPU: 16 cores |
Connection Pooler for Database |
PgBouncer |
CPU: 2 cores |
Databases |
PostgreSQL |
CPU: 16 cores |
Caching Databases |
Redis |
CPU: 2 cores |
Object Storage |
Min.io, S3 compatible |
Based on the deployment & replication |
File Storage |
- |
Based on the deployment & replication |
Monitoring & Alerts |
Zabbix |
CPU: 4 cores |
Log Aggregation |
Grafana Loki |
Based on the deployment & replication |
These specifications are just a starting point. The platform needs to scale up or down depending on the specific use case and performance requirements.
In configuring your OpenSPP deployment, there are three principal infrastructure alternatives.
The 'On-Premise' model involves setting up the system within the private data center or facility, offering the utmost control over infrastructure, data privacy, and security.
The 'Cloud' model leverages the vast capabilities of cloud computing platforms, ensuring scalability and flexibility while reducing the overhead of infrastructure management.
The 'Hybrid' model is a blend of on-premises and cloud deployments, combining the scalability of cloud services with the increased control of on-premises systems.
The selection among these options should align with the organization's/countries’s specific requirements, budget constraints, and overarching IT strategy.
C. The single-node deployment#
The single-node deployment refers to installing and configuring OpenSPP on a single VM, typically for testing or small-scale production purposes. This deployment type involves setting up all the required OpenSPP modules on a single physical or virtual machine, ensuring simplified management and a reduced resource footprint.
The specifications required for a single-node deployment of OpenSPP largely depend on the intended use case of the system. The requirements may be relatively minimal for a testing or development setting, entailing a multi-core processor, adequate RAM, and sufficient storage capacity. However, for small-scale production environments, the requirements can escalate significantly, mandating top-tier multicore processors, substantial amounts of RAM, and high-performance, capacity-rich storage. The network interface should be correspondingly high-speed. These recommendations should be adapted based on the specific computational load and throughput anticipated for the system. For instance, systems expected to handle high traffic volumes will necessitate more robust hardware and expanded network capabilities to ensure seamless operation.
A thorough assessment of your system usage should be carried out to determine hardware specifications for deployment.
Modular architecture#
OpenSPP is designed to be used standalone with just the core functionalities or with other components.
The previous diagram shows the core components of OpenSPP. Those components provide APIs that allow you to replace the default implementation with your own.
For example, the eligibility calculation can be delegated to a third-party service that has access to other data and just return the eligibility result to OpenSPP.
Furthermore, as OpenSPP is based on the ERP Odoo and use the standard models provided by Odoo, you have access to the thousands of applications available in the Odoo App Store or build your own.
Example components for a mid-size project#
Example components for a large project#
