Republic of Uganda

MINISTRY OF WORKS AND TRANSPORT

Department of Transport Regulation and Safety

SOLUTION (ARCHITECTURE) DESIGN

DOCUMENT

CONSULTANCY TO DEVELOP AN E-SERVICES WEB PORTAL

(PHASE 1) FOR THE ASSESSMENT AND COLLECTION OF NON-TAX
REVENUE (NTR)

REF: MOWT/NCONS/20-21/00242

Presented by

6th Floor Rumee Towers (Northern Wing), 19 – 24 Lumumba Avenue

P.O. Box 3856 Kampala, Tel: +256 200 908055, 0772 377 777 Email: [email protected]

Version: 1.0 - NOVEMBER 2021

 Contents
1 DOCUMENT CONTROL ................................................................................................................. 5
1.1 Preparation .................................................................................................................................. 5
1.2 Revision History ......................................................................................................................... 5
2 SCOPE.................................................................................................................................................. 6
2.1 Solution Scope ............................................................................................................................ 6
2.2 Objectives and Constraints ....................................................................................................... 6
2.2.1 Objectives ............................................................................................................................ 6
2.2.2 Constraints .......................................................................................................................... 6
2.3 References ................................................................................................................................... 6
2.3.1 Reference Documents ........................................................................................................ 6
3 HIGH LEVEL DESIGN...................................................................................................................... 8
3.1 Solution Overview ..................................................................................................................... 8
3.1.1 System User Context Diagram ......................................................................................... 8
3.1.2 System Architecture ........................................................................................................... 9
3.2 Design Choices ......................................................................................................................... 10
3.2.1 Front End Layer................................................................................................................ 10
3.2.2 Backend Layer .................................................................................................................. 10
3.2.3 Database Layer ................................................................................................................. 11
3.2.4 Backend - Front End Interaction .................................................................................... 11
3.3 Interfaces with other Systems................................................................................................. 12
3.4 Internet Access.......................................................................................................................... 12
3.5 Deployment/ Physical View .................................................................................................. 13
3.5.1 Staging ............................................................................................................................... 13
3.5.2 Production ......................................................................................................................... 13
3.5.3 Training and QA .............................................................................................................. 13
4 DETAILED DESIGN ........................................................................................................................ 14
4.1 Staging Environment ............................................................................................................... 14
4.1.1 VPS Specifications ............................................................................................................ 14
4.2 Hosting/ Production Environment ....................................................................................... 14
4.2.1 Core Equipment ............................................................................................................... 14
 4.2.2 The Datacenter .................................................................................................................. 15
4.3 Database and Reporting .......................................................................................................... 20
4.3.1 MySQL Shell ..................................................................................................................... 20
4.4 Backup Services ........................................................................................................................ 21
4.5 Network Services ..................................................................................................................... 21
4.6 Monitoring Services ................................................................................................................. 21
5 DESIGN CONSIDERATIONS AND ASSUMPTIONS ............................................................... 22
5.1 Considerations .......................................................................................................................... 22
5.1.1 Compatibility and Interoperability................................................................................ 22
5.1.2 Extensibility ...................................................................................................................... 22
5.1.3 Modularity ........................................................................................................................ 22
5.1.4 Fault-tolerance .................................................................................................................. 22
5.1.5 Maintainability ................................................................................................................. 22
5.1.6 Reliability .......................................................................................................................... 22
5.1.7 Robustness ........................................................................................................................ 22
5.1.8 Security .............................................................................................................................. 22
5.1.9 Usability............................................................................................................................. 23
5.1.10 Performance ...................................................................................................................... 23
5.1.11 Portability .......................................................................................................................... 23
5.1.12 Scalability .......................................................................................................................... 23
5.2 Assumptions ............................................................................................................................. 24
5.2.1 User Competence & System Simplicity ........................................................................ 24
5.2.2 Integration with Other Systems ..................................................................................... 24
5.2.3 System Availability .......................................................................................................... 24
6 DOCUMENT ACCEPTANCE AND SIGN OFF .......................................................................... 25
7 APPENDIX ........................................................................................................................................ 27
7.1 Glossary ..................................................................................................................................... 27
7.2 Acronyms .................................................................................................................................. 30
 Table of Figures

Figure 1: NTR System User Context Diagram ....................................................................................... 8

Figure 2: System Architecture .................................................................................................................. 9
Figure 3: Interaction between the front and backend through the Webservice .............................. 12
Figure 4: GUI representation of oVirt ................................................................................................... 17
Figure 5: oVirt Engine Web Administration ........................................................................................ 18
1 DOCUMENT CONTROL
1.1 Preparation

Preparation Name Title Date

Draft Vincent Kaabunga Solution Architect November 2021

Contribution Simon Kaweesi Product Developer November 2021

1.2 Revision History

Revision Name Tile Date

Review Kennedy Nayebare Project Manager November 2021

Review Carol M Mugume Project Sponsor November 2021

2 SCOPE
2.1 Solution Scope
This document describes the implementation details of the MoWT TRS NTR System. The
solution will consist of a two major functions for its users. First to assessment portal where
applicants can select services to make payments for, and the second to the software backend/
Backoffice where MoWT users will access interfaces for executing their day-to-day tasks
including accessing decision support tools and configuration tools among others.

This document will not specify any actual services or the testing of the software.

2.2 Objectives and Constraints

2.2.1 Objectives

The primary objective is to build a robust web-based solution for the MoWT Department of
Transport Regulation and Safety clients to be able to quickly and conveniently make
assessments and payments for desired services using either desktop computers, laptops, tablets
or mobile phones.

The solution will be integrable with other government systems to improve service delivery and
information sharing across all stakeholders.

2.2.2 Constraints

Achieving the quick turnaround time required by TRS to deliver the product is dependent on
third-party (e-Tax System, Licensing System) integration partners’ involvement is timely.

It is envisaged that critical stakeholder current integration implementations will limit fluidity in
the design to achieve certain workflows. In this case we shall have consultative meetings on
workarounds to achieve the desired outcomes.

2.3 References
Before consulting and or implementing our SDLC system development methodology, it was
important to adhere to and comply with the standards set forth by Government. Complying
with these standards helps systems and organizations stay within the laws and regulations of
the Government of Uganda (GoU) in regards to system design and information sharing.

2.3.1 Reference Documents

The Finance Act, 2014

Traffic and Road Safety Act,1998

The Access to Information Act (2005)

Computer Misuse Act, 2011, 2010

URS for payment processing – URA

URS Payment Interface between URA and MOWT

3 HIGH LEVEL DESIGN
3.1 Solution Overview
3.1.1 System User Context Diagram

Figure 1: NTR System User Context Diagram

3.1.2 System Architecture

Figure 2: System Architecture

 3.2 Design Choices
The Solution will be designed using a three-tier approach with the frontend layer, backend
layer and database layer.

3.2.1 Front End Layer

React JS for UI Component Design and Redux for State Management

Reason for React Js

1. Speed

2. Scalability

3. Simplicity

React JS will be used to develop the Clients’ Self-Service Web Application as well as the
Administrator Web Application (Admin Panel) and the BackOffice Interfaces for MoWT users.

3.2.2 Backend Layer

Python – Django Framework 3.3.9

Django is a high-level python web frame that enable rapid development of secure and
maintainable websites. In this project, Django will allow the backend engineer to modularize
the solution by building the different backend features as Apps and further integrating them
into a project which the users will interact with

Reasons for Django

1. Scalability

2. Security

3. Speed

3.2.2.1 The Administrator Panel/ BackOffice

The backend shall also consist of an Administrator Panel/ BackOffice which will be securely
accessed only by authenticated and authorized users to manage the different tasks and
configurations of the NTR Application. This Application shall allow the following user roles

1. Accounts

2. Licensing Officer
 3. Chief Licensing Officer

4. System Administrator

The Administrator Panel shall offer the following features

1. User Management

2. System Role Assignment

3. Service (“Tax Heads”) Price Configurations

4. Analytics and Reporting

3.2.3 Database Layer

MySQL Enterprise Edition is the database server that will be used in this project. This offers
high availability, scalability and monitoring features needed in ensuring that the solution meets
its goals. The Enterprise Edition offers the following benefits

1. MySQL Enterprise Dashboard to monitor the operations of the database

2. MySQL Replication Monitor to allow the database administrator manage database

replications

3. Offers full, incremental, partial backups

4. Offers point in time recovery

5. Offers high availability

3.2.4 Backend - Front End Interaction

The front end shall interact with the backend end through a web service built in Django. React
JS on the front interacts with the backend end through consuming a REST API built in Django
as shown below
 Figure 3: Interaction between the front and backend through the Webservice

Having a Rest API on the backend allows the solution to be easily scalable and has added
advantage of the ability to integrate the solution easily with other existing systems.

3.3 Interfaces with other Systems

Integration with other systems will be possible through a web service by consuming the REST
API.

3.4 Internet Access

Internet access to the production environment will be provided by NITA-U as the primary
provider. A secondary ISP, who will be determined later) will provide a second (lower
bandwidth) link to the solution for redundancy.

The primary link will have two public IP Addresses. One for access and the other for
maintenance.
The two links will be aggregated and configured with automatic failover to ensure system high
availability.

3.5 Deployment/ Physical View

3.5.1 Staging

Software staging and testing will be done on the consultant’s VPS and can be accessed by
accessing the following link.

https://ntr.cml.ug

The proposed specification details of the staging environment are detailed in section 3.1.

3.5.2 Production

The production environment will be accessible via a MoWT URL which will be determined at a
later time.

The proposed set up and configuration of the production environment is detailed in section 3.2.

3.5.3 Training and QA

The Quality Assurance and Training teams will use the staging server for their duties.
4 DETAILED DESIGN
4.1 Staging Environment
The staging environment is a cloud-hosted VPS which can be accessed via the following URL.

https://ntr.cml.ug

4.1.1 VPS Specifications

IP Address: 194.195.215.94

Processor: 4 CPU Cores

RAM: 8GB RAM

Storage: 160 GB

Swap Image: 512 MB

OS: Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0-88-generic x86_64)

4.2 Hosting/ Production Environment

4.2.1 Core Equipment

The following is the proposed minimum equipment that will be required to set up the
production environment.

Equipment Minimum Specifications Quantity

Intel Xeon 4110 Silver

16 GB RAM
Application Server 2
3 x 300 SAS SATA HDD
2 x Gigabit Ethernet Interfaces

Intel Xeon 4110 Silver

32 GB RAM
Storage Server 2
3 x 300 SAS SATA HDD
2 x Gigabit Ethernet Interfaces
 Threat Prevention throughput: 300 – 600
Mbps
VLAN Interfaces: 128
DPI SSL: 300 Mbps
Firewall 1
IPSec throughput: 1.5Gbps
Max Connections: 500,000 with DPI
IPSec Client: 10
IMIX Throughput: 700Mbps

16-port Gigabit Interfaces

Switch 1
2x 10G Interfaces

Router To be determined (NITA-U) 1

Equipment Rack 37U Rack 1

Power Redundancy and Delivery 5KVA Online UPS/ Inverter 1

HVAC System 24,000 BTU 1

Assorted Setup Cables and Accessories To be determined 1

4.2.2 The Datacenter

4.2.2.1 Setting Up the Datacenter

The installation procedure is a 3-step process that will involve:

1. Rack, stack and cabling of all the equipment

2. Power on tests, initialization of equipment
3. Configuration of Datacenter
 4.2.2.2 Virtual Datacenter

The NTR System data center will be installed on a virtualized environment where both
Application and Database will be installed. The virtualized infrastructure will achieve the
following objectives for the NTR System

• Resource utilization. The resources on the physical hosts installed will be used optimally

• High Availability. Virtual Machines (VM) installed on this environment will be able to
move from one host to another

• Centralized management and resource allocation. Through a central management

engine, virtual machines can be managed, monitored and provisioned.

The virtualized environment will run Ovirt - an open-source data center virtualized platform
which offers large-scale, centralized management for server and desktop virtualization. It
provides Kernel-based virtual machine management for a multi-node virtualization and as such
KVM (Kernel-based Virtual machines) are part of a virtualization infrastructure that turns the
Linux kernel into a hypervisor.

oVirt consists of two parts

• oVirt Engine: Acts as the control center for oVirt environments. It enables admins to
define hosts and networks as well as add storage, create VMs and manage user
permissions. A GUI is included which manages oVirt infrastructure resources. The oVirt
engine will be configured as a standalone server.

• oVirt Nodes: This is a server that runs on CentOS, Fedora or RHEL with virtual desktop
and server manager (VDSM) daemon and KVM hypervisor. The VDSM controls the
resources available to the node, including compute, networking and storage resources.

Below are the specifications required for oVirt Engine

Hostname ovirtengine.mowt_ntr.go.ug

IP Address X.X.X.X

Version 4.X

RAM 16GB

OS Cent OS 7.0 Core

 Disk Space >50GB

Below is a GUI representation of the engine: https:// ovirtengine.mowt_ntr.go.ug

Figure 4: GUI representation of oVirt

Figure 5: oVirt Engine Web Administration
Below are the specifications required for oVirt Nodes

Hostname ovirtnode01/02.mowt_ntr.go.ug

IP Address X.X.X.X

Version 4.X

RAM >32GB

OS 4.X iso

Disk Space >500GB

Hostname ovirtnode03/04.mowt_ntr.go.ug

IP Address X.X.X.X

Version 4.X

RAM >32GB

OS 4.X iso

Disk Space >500GB

4.2.2.3 Storage

Storage will be mounted to the Virtual environment through NFS. The following NFS mount
points will be created. These NFS shares will be configured on the storage systems before they
are connected to the virtual environment. Each Storage Server system will be configured with
minimum 512GB installed capacity

• /exports/vmstorage - This will contain all the hard disk images for the virtual machines

• /exports/iso - This will contain ISO files for the OS

At a storage level, the storage server at the datacenter will replicate to the one at NITA-U DR
site through Real-Time Remote Replication (RTRR). Real-time Remote Replication (RTRR) is a
powerful backup feature to back up new and modified files immediately to another folder (on
the storage server or an external drive) or a remote NAS. RTRR improves backup efficiency and
reduces backup time. It also supports data backup from the storage server to a remote FTP
server and vice versa.
To set up RTRR;

• Login to storage server as an administrator and go to "Applications” > "Backup Server”.

• Under the "RTRR Server” tab, click "Enable Real-time Remote Replication Server”.

• The default service port is 8899; you do not need to change the port number.

• Enter a password for RTRR backup and verify the password, then click "Apply”.

In this configuration only the /iso and /vmstorage will only be configured at the MoWT
Datacenter and replicated to DR. The remainder of the capacity will be used for expansion at a
later time.

Hostname nfshq.mowt_ntr.go.ug

IP X.X.X.X
Address

Mount /vmstorage (500GB)

Points
/iso (500GB)

Hostname nfsdr.mowt_ntr_2.go.ug

IP X.X.X.X
Address

Mount /vmstorage (500GB)

Points
/iso (500GB)

4.3 Database and Reporting

4.3.1 MySQL Shell

MySQL Shell enables users to set up and run reports to display live information from a MySQL
server instance, such as status and performance information. This is very crucial for DB
administrators to optimize the database for performance and improved user experience.

MySQL Shell's reporting facility supports both built-in reports and user-defined reports. The
reporting facility is available from MySQL Shell 8.0.16. Reports can be created directly at the
MySQL Shell interactive prompt, or defined in scripts that are automatically loaded when
MySQL Shell starts.

4.4 Backup Services

Backup Services will be provided by NITA-U.

4.5 Network Services

The following will be the network services required by the system.

Permit/ Protocol Source Destination Source Dest Port Service

Deny Port

Permit TCP External Website WWW 443 443 HTTPS

Permit TCP Web Servers App Server 3080 3080 TCP

Permit TCP Web Server App Server 3443 3443 TCP

Permit TCP App Server DB 1521 1521 TCP

Permit TCP Web Services App Server 1622 1622 TCP

4.6 Monitoring Services

Monitoring will be defined at a later time.
5 DESIGN CONSIDERATIONS AND ASSUMPTIONS
5.1 Considerations
The following were the design considerations taken into account while scoping the NTR System
solution.

5.1.1 Compatibility and Interoperability

The system is able to integrate and operate with other government systems.

5.1.2 Extensibility

New capabilities can be added to the system without major changes to the underlying
architecture.

5.1.3 Modularity

The system design comprises well defined, independent modules and components which leads
to better maintainability. The components will be implemented and tested in isolation before
being integrated to form the desired software system.

5.1.4 Fault-tolerance

The system is resistant to and able to recover from component failure.

5.1.5 Maintainability

Care in design was made for easily bug fixes or functional modifications to be accomplished.

5.1.6 Reliability

The system is able to perform a required function under stated conditions for a specified period
of time.

5.1.7 Robustness

The system is able to operate under stress or tolerate unpredictable or invalid input.

5.1.8 Security

The system is able to withstand and resist hostile acts and influences.
 5.1.9 Usability

The system user interfaces must be usable for its target user/audience. Default values for the
parameters must be chosen so that they are a good choice for the majority of the users.

5.1.10 Performance

The system performs its tasks within a time-frame that is acceptable for the user, and does not
require too much memory.

5.1.11 Portability

The system should be usable across a number of different conditions and environments.

5.1.12 Scalability

The software adapts well to increasing data or added features or number of users.
 5.2 Assumptions
The following were the assumptions made while scoping the NTR System solution.

5.2.1 User Competence & System Simplicity

The system should be very user friendly even and operable by a user who does not necessarily
know English.

5.2.2 Integration with Other Systems

Other systems expected to integrate with this solution have already existing APIs.

5.2.3 System Availability

This ISPs can guarantee 99.9% service uptime to ensure that the system is always accessible.
6 DOCUMENT ACCEPTANCE AND SIGN OFF
For Ministry of Works & Transport

………………………………… …………………………………………………………….
Signature Name
Date Title

………………………………… …………………………………………………………….
Signature Name
Date Title

………………………………… …………………………………………………………….
Signature Name
Date Title

………………………………… …………………………………………………………….
Signature Name
Date Title
For Computer Medics Ltd (CML)

………………………………… …………………………………………………………….
Signature Name: Carol Mbabazi
Date Title: Project Sponsor

………………………………… …………………………………………………………….
Signature Name: Kennedy Nayebare
Date Title: Project Manager/ Business Analyst

………………………………… …………………………………………………………….
Signature Name: Simon Kaweesi
Date Title: Product Developer/ System Architect
7 APPENDIX
7.1 Glossary

Term Definition

App Server An application server is a server that hosts applications. An

application server framework provides both facilities to create
web applications and a server environment to run them.

Backend Layer The backend layer is also called the data access layer of
software or hardware and includes any functionality that
needs to be accessed and navigated to by digital means.

Business Layer The Business Layer is the place where all the business/domain
logic, i.e., rules that are particular to the problem that the
application has been built to handle, lives.

Data Access Layer A data access layer (DAL) in computer software is a layer of a
computer program which provides simplified access to data
stored in persistent storage of some kind, such as an entity-
relational database.

Data Layer A data layer is a JavaScript object that collects data on your
website in a standardized way. Every tool you hook up to your
website — analytics, heatmapping, live chat, etc. — accesses
this one layer of data, which ensures two things: Each tool gets
the data it needs. The data each tool uses is the same.

Django Framework Django is a high-level Python web framework that encourages

rapid development and clean, pragmatic design.

Failover Failover is the ability to switch automatically and seamlessly to

a reliable backup system. When a component or primary
system fails, either a standby operational mode or redundancy
should achieve failover and lessen or eliminate negative
impact on users.

Front End Layer Frontend is the presentation layer, it’s that part of an
application, which the user can see.
IP Address An IP address is a unique address that identifies a device on
the internet or a local network. IP stands for "Internet
Protocol," which is the set of rules governing the format of data
sent via the internet or local network.

MySQL MySQL is an Oracle-backed open-source relational database

management system (RDBMS) based on Structured Query
Language (SQL). MySQL runs on virtually all platforms,
including Linux, UNIX and Windows. Although it can be used
in a wide range of applications, MySQL is most often
associated with web applications and online publishing.

Presentation layer In the seven-layer OSI model of computer networking, the

presentation layer is layer 6 and serves as the data translator
for the network.[1][2] It is sometimes called the syntax layer.

Production Environment A production environment is where the latest versions of

software, products, or updates are pushed live to the intended
users.

Python Python is an interpreted, object-oriented, high-level

programming language with dynamic semantics. Its high-level
built-in data structures, combined with dynamic typing and
dynamic binding, make it very attractive for Rapid Application
Development, as well as for use as a scripting or glue language
to connect existing components together.

React JS React is a JavaScript library created for building fast and

interactive user interfaces for web and mobile applications. It is
an open-source, component-based, front-end library
responsible only for the application’s view layer.

Replication Replication in computing involves sharing information so as to

ensure consistency between redundant resources, such as
software or hardware components, to improve reliability, fault-
tolerance, or accessibility.

REST API A REST API (also known as RESTful API) is an application

programming interface (API or web API) that conforms to the
constraints of REST architectural style and allows for
interaction with RESTful web services. REST stands for
representational state transfer.
Service Layer Service layer is an architectural pattern, applied within the
service-orientation design paradigm, which aims to organize
the services, within a service inventory, into a set of logical
layers. Services that are categorized into a particular layer
share functionality. This helps to reduce the conceptual
overhead related to managing the service inventory, as the
services belonging to the same layer address a smaller set of
activities.

Staging Environment A staging environment or staging site is a copy of the live web
application and is the last step in the deployment process
before changes are deployed production.
By having a staging environment that is a copy of the
production environment, system developers and users are able
to test new changes made before they are released.

Web Server A web server is software and hardware that uses HTTP
(Hypertext Transfer Protocol) and other protocols to respond
to client requests made over the World Wide Web. The main
job of a web server is to display website content through
storing, processing and delivering webpages to users. Besides
HTTP, web servers also support SMTP (Simple Mail Transfer
Protocol) and FTP (File Transfer Protocol), used for email, file
transfer and storage.

Web Services A Web service is a method of communication between two

electronic devices over a network. It is a software function
provided at a network address over the Web with the service
always-on as in the concept of utility computing. Many
organizations use multiple software systems for management.
 7.2 Acronyms

Acronym Meaning

BTU British Thermal Unit

CML Computer Medics Ltd

CPU Central Processing Unit

DNS Domain Name System

DPI Deep Packed Inspection

DR Disaster Recovery Site

FTP File Transfer Protocol

GoU Government of Uganda

GUI Graphical User Interface

HQ Head Quarters

HTTPS Hypertext Transfer Protocol Secure

HVAC Heating, Ventilation and Air Conditioning

IPSec Internet Protocol (IP) Security

ISO International Organization for Standardization

ISP Internet Service Provider

KVM Kernel-based Virtual Machine

MoWT Ministry of Works and Transport

NAS Network Attached Storage

NFS Network File System

NITA-U National Information Technology Authority, Uganda

NTR Non-Tax Revenue

Acronym Meaning

OS Operating System

OS Operating System

QA Quality Assurance

RAM Random Access Memory

RTRR Real-Time Remote Replication

SDLC Software Development Life Cycle

TCP Transmission Control Protocol

TRS Department of Transport Regulation and Safety

URA Uganda Revenue Authority

URL Uniform Resource Locator

VDSM Virtual Desktop Server Manager

VM Virtual Machine

VPS Virtual Private Server

www World Wide Web