Software Architecture Compliance Management Product

Document Change Control

List of Approvers

1. Introduction

This document outlines the software architecture for the Odoo-based project. It provides a high-level design view and architectural decisions.

2. System Overview

The system is an enterprise resource planning (ERP) platform built using Odoo 17. Modules include:- Finance, CRM, and custom applications like e-Approvals and Service Desk.

3. Abbreviations & Definitions

4. Architectural Principles

- Use standard Odoo architecture practices- Avoid core modifications- Modular and maintainable code- Arabic language support- Compliance with local regulations (e.g., NCA, Nafath)

5. High-Level Architecture Diagram

•  Context Diagram. (mandatory)

5.1 External Entities:

5.2 Internal Entities:

1. (HR) As an Example: Manage compliance responsibilities with the organisational structure and employee roles. This integration enables accountability, workflow routing, and access control based on departments and job positions.
2. (Tasks) As an Example: The System is intended to help users and teams efficiently plan, assign, track, and complete tasks. 
3. (Document) As an Example: Manage all compliance-related files are centrally stored, version-controlled, and accessible based on roles and departments.
4. (Emails) As an Example: This focuses specifically on how email features integrate with compliance and task management, including auto-notifications, chatter, and template usage.

5.3 Architecture Design. (mandatory)

• Colors:
  • Default Modules (Color: Light Green)
  • Customized Modules (Color: Light Blue)
  • Built From Scratch (Color: Light Red)
  • Third Pary Modules (Color: Light Orange)

6. Client Layer (Backend-End)

- User Interfaces (UI): The system will offer an intuitive, user-friendly interface for the end user to access standards and requirements to manage their tasks.

- Technologies: Odoo v17, Python 3.10 , Postgress 16 for DB and efficient component-based architecture.

- Access Points:  - Web Application: A browser-based interface where users can access standards and requirements, apply for measurement, and track their measurement status.- Mobile APP

- Authentication & Authorization: Use OAuth 2.0 or JWT tokens for secure access and Single Sign-On (SSO) across services.        

7. Service Layer (Business Logic)

- Service-Oriented Architecture (SOA): Modular, reusable, and loosely coupled services.- Microservices:

• Compliance Management: Create, update, and archive measurements for all partners and manage standards, requirements and track status.
• Task Management: Create, assign, update, and close tasks; manage workflows.
• Document: Upload, version, and serve measurement files for all partners.
• Notification Service: Sends notifications (SMS, email) to end-users about the requirement status.

- API Gateway: Expose services via REST, using API Gateway tools like Kong, AWS API Gateway, or Nginx.        

8. Data Layer (Database & Storage)

- Database: PostgreSQL for structured data (user info, transactions, compliance); MongoDB for unstructured data (logs, notifications).- Document Management System (DMS): Store documents (measurements, approval proof attachment) using Odoo Filestore or Google Cloud Storage.        

9. Integration Layer

- External Systems Integration: Connect with external governmental or regulatory systems for verification.

• - Component Diagram. (optional)
• - ERD. (optional)

10. Key Modules and Interactions

- HR: Manage and assign the department related to the standard to receive notifications related to that standard and track their requirements.-Task Management: Tasks are created, assigned to employees linked to standards, and tracked through the Task Management module.-Documents: Such as approval proof attachments related to each measurement, managed through the Documents module.

11. External Interfaces(Nothing)

12. Architectural Decisions

Adding link of DAR Related to Software Architecture

- Use PostgreSQL instead of MySQL for full Odoo support- Use XML-RPC for internal integrations instead of direct DB calls

13. Non-Functional Requirements

- Performance: < 3 seconds average response time- Availability: 99.9% uptime required- Security: OAuth2, SSL/TLS, API Keys- Scalability: Multi-tenant support for future SaaS expansion

• - Server Structure Diagram. (Optional)