Enterprise Architecture Software Architecture

Document Change Control

List of Approvers

1. Introduction

 This document outlines the software architecture and high-level design decisions for the EA Project.  

2. System Overview

EA follows industry standards (like TOGAF) but is customized for the Saudi government context. It is built on four core architecture layers that you will need to document for your enterprise:

1. Business Architecture (BA): Defines your entity's services, processes, and strategy. Question to ask: What services does my entity provide to citizens or other government bodies?
2. Data Architecture (DA): Defines how data is structured, stored, and shared. Key focus: Implementing the National Data Management Office (NDMO) standards.
3. Application Architecture (AA): Maps out your software portfolio. Key focus: Which applications are redundant? Which ones need to talk to the National Information Center (NIC)?
4. Technology Architecture (TA): The underlying infrastructure (Cloud, Servers, Network). Key focus: Moving to the Government Cloud (Deem) or approved cloud providers.

3. Abbreviations & Definitions

4. Architectural Principles

• Adherence to standard Odoo architecture practices
• Avoidance of core modifications
• Emphasis on modular and maintainable code
• Support for the Arabic language
• Compliance with local regulations (e.g., NCA, Nafath)

5. High-Level Architecture Diagram

•  Context Diagram

.1 External Entities:

1. (Nora):
   • Represents Base of EA in the Saudi Arabia.
   • EA interacts with this system to process and update EA.
2. (Nafath):
   • Nafath is likely a government identity verification system used for user authentication.
   • EA communicates with Nafath to verify user identity and validate credentials.

5.2 Internal Entities:

1.(HR System) As Example:

• Represents the licensing system or authority responsible for managing license issuance, renewals, and related activities.
• EA interacts with this system to process and update licenses.

2.(Emails) As an Example:

• Represents the licensing system or authority responsible for managing license issuance, renewals, and related activities.
• EA interacts with this system to process and update licenses.

5.3 Architecture Design.

• Colors:
  • Default Modules: Light Green
  • Customized Modules: Light Blue
  • Built From Scratch: Light Red

6. Client Layer (Front-End)

• User Interfaces (UI): Provides an intuitive, user-friendly interface for end-users to access electronic services and manage their licenses.
• Technologies: Odoo v17, Python 3.10, PostgreSQL 16 for database, and an efficient component-based architecture.
• Access Points: Web Application (browser-based interface for service access, license applications, status tracking, and payments).
• Authentication & Authorization: Utilizes 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): Designed with modular, reusable, and loosely coupled services.
• Microservices:
  • Electronic Services Management: Manages service requests, workflows, and fulfillment.
  • License Management: Manages the lifecycle of licenses (application, issuance, renewal, revocation).
  • Payment Gateway: Integrates with third-party payment services like Sadad.
  • Notification Service: Sends notifications (SMS, email) to end-users about service/license status.
  • Analytics Service: Tracks user activity and service utilization.
• API Gateway: Exposes services via REST, using API Gateway tools such as Kong, AWS API Gateway, or Nginx.

8. Data Layer (Database & Storage)

• Database: PostgreSQL for structured data (user information, transactions, licenses) and MongoDB for unstructured data (logs, notifications).
• Document Management System (DMS): Stores documents (scanned licenses, certificates) using Odoo Filestore or Google Cloud Storage.

9. Integration Layer

• External Systems Integration: Connects with external governmental or regulatory systems for verification.
• Third-Party APIs: Integrates for payment processing and address verification, such as Nafath.
• Enterprise Service Bus (ESB): Employs Apache Camel to orchestrate communication between services and external systems.

• - Component Diagram.

• - ERD.

11. External Interfaces

11.1 Nafath

  Interface Summary

• • • Interface Name: Nafath Authentication API
    • Direction: Outbound
    • Protocol: HTTPS (REST API)
    • Format: JSON
    • Adding Swaqqer or Postman Collection Reference Link

11.2 Active Directory

  Interface Summary

• • • Interface Name: Nafath Authentication API
    • Direction: Outbound
    • Protocol: HTTPS (REST API)
    • Format: JSON
    • Adding Swaqqer or Postman Collection Reference Link

12. Architectural Decisions

   - 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 

14. Integrations

• Swagger: Swaggerhubapp.swaggerhub.com/apis/MELBADRY_1/Mwan-...
• Postman Collection: Swaggerhubapp.swaggerhub.com/apis/MELBADRY_1/Mwan-...