<Project Name> Solution Architecture
Technical Document
Date: <dd/mmm/yyyy>
Version: <nn.nn>
<Company Name>
<Company Logo>
Solution Architecture Submission for <Project Name>
Submission Details
Project Name:
<Project name>
Submission Contact Name:
<Contact name>
Submission Contact Title:
<CTO / CIO / Officer / IMU / Supplier>
Submission Contact Details:
<email> / <telephone> / <mobile>
Project Completion Date:
<Date>
Supplier:
<Supplier name>
Ministry / Department /
Company
<Entity name>
Supplier Contact Person: <Supplier contact
person>
Supplier Contact Details:
<email> / <telephone> / <mobile>
Client Name:
<Client name>
Client Contact Details:
<email> / <telephone> / <mobile>
Ministry / Department /
Company
<Entity name>
Table of Contents
SUBMISSION DETAILS ...................................................................................................................... 1
1.
GLOSSARY OF TERMS .............................................................................................................. 3
INTRODUCTION .................................................................................................................................. 4
1.1
1.2
SYSTEM DESIGN SECTIONS........................................................................................................ 4
TSG OFFERS ASSISTANCE TO PUBLIC SECTOR ORGANISATION................................................. 5
2.
SYSTEM DESIGN CHANGE LOG ............................................................................................. 6
3.
GATE 1: BASIC SOLUTION PROFILE ..................................................................................... 7
3.1
3.2
3.3
3.4
4.
GATE 2: PRELIMINARY SYSTEM DESIGN ......................................................................... 17
4.1
4.2
4.3
4.4
5.
HIGH LEVEL BUSINESS SCOPE OF SOLUTION ............................................................................. 7
BASIC SYSTEM CHECKLIST........................................................................................................ 8
FUNCTIONAL SYSTEM DESCRIPTION ....................................................................................... 12
CONCEPTUAL SYSTEM DESIGN DESCRIPTION .......................................................................... 16
PRELIMINARY SYSTEM CHECKLIST ......................................................................................... 17
DEVELOPMENT QUALITY DESCRIPTION .................................................................................. 19
PRELIMINARY SYSTEM DESIGN DESCRIPTION ......................................................................... 20
SYSTEM ARCHITECTURE QUALITY DESCRIPTION .................................................................... 21
GATE 3: DETAIL SYSTEM DESIGN....................................................................................... 23
5.1
DETAIL SYSTEM DESIGN CHECKLIST ...................................................................................... 23
5.2
DETAIL SYSTEM DESIGN DESCRIPTION ................................................................................... 27
5.2.1
Detail System Design – Infrastructure Architecture ....................................................... 27
5.2.2
Computing Resources Required...................................................................................... 28
5.2.3
Network Access Requirement (Type 1A, Type 1B and Type 2 Hosting) ......................... 29
5.2.4
Detail System Design – Application Architecture........................................................... 29
6.
TECHNICAL ARCHITECTURE DOMAINS .......................................................................... 30
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
7.
NETWORK DOMAIN: ................................................................................................................ 30
APPLICATION DOMAIN: ........................................................................................................... 30
DATA DOMAIN: ....................................................................................................................... 30
SYSTEMS INTEGRATION DOMAIN: ........................................................................................... 30
GROUPWARE DOMAIN: ............................................................................................................ 30
PLATFORM DOMAIN: ............................................................................................................... 30
ENTERPRISE MANAGEMENT DOMAIN: ..................................................................................... 30
SECURITY DOMAIN: ................................................................................................................ 30
APPENDIX A – SERVICE CONTRACT/ ADAPTER DEFINITION .................................... 31
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 2 of 34
1. Glossary of terms
This section includes the descriptions of all abbreviations, terms or terminologies used
throughout the document.
Project Type:
New System
A system being submitted for Solution Architecture Assessment for
the first time which has never been approved.
Project Type:
Upgrade System
An Upgrade of the System refers to an addition/change of any of the
component/s, or any other change possible within the existing
System Solution Architecture which has already been approved.
Cold Site
A cold site is the most inexpensive type of backup site for an
organization to operate. It does not include backed up copies of data
and information from the original location of the organization, nor
does it include hardware already set up. The lack of hardware
contributes to the minimal startup costs of the cold site, but requires
additional time following the disaster to have the operation running
at a capacity close to that prior to the disaster.
(In the context of Backups)
Warm Site
(In the context of Backups)
Hot Site
(In the context of Backups)
Private Runtime
Environment (PRE)
Principles
A warm site is, quite logically, a compromise between hot and cold.
These sites will have hardware and connectivity already established,
though on a smaller scale than the original production site or even a
hot site. Warm sites will have backups on hand, but they may not be
complete and may be between several days and a week old. An
example would be backup tapes sent to the warm site by courier.
A hot site is a duplicate of the original site of the organization, with
full computer systems as well as near-complete backups of user
data. Real time synchronization between the two sites may be used
to completely mirror the data environment of the original site using
wide area network links and specialized software. Following a
disruption to the original site, the hot site exists so that the
organization can relocate with minimal losses to normal operations.
A Private Runtime Environment (PRE) is an environment which
enables Contractors to locate their Solution in a segregated
environment within premises provided by MITA.
Within this
environment, the following applies:
(a) MITA will provide the space for the Contractor to install its
Solution;
(b) The Contractor will be fully responsible for operating,
administering and managing its Solution;
(c) At its discretion, MITA may provide the necessary ICT
Computing Resources itself;
The PRE will be governed by the terms of another document (refer
to
PRE
Documentation
https://www.mita.gov.mt/MediaCenter/PDFs/3_TSG-REPPrivateRuntimeEnvironment_Public-v2.0.pdf);
The
document
outlines the responsibilities of MITA and the Contractor in relation to
the PRE.
PSO
Public Sector Organisation
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 3 of 34
Introduction
The Solution Architecture Template has been designed to enable Public Sector Organisation
(PSO) to provide an increasing amount of detail to the Technology and Systems Governance
(TSG) over the life of a project. PSO requesting Project Approval will be required to complete
this template, section by section, during the various phases of a project. To facilitate this
process, this template has been separated into four sections.
1.1
System Design Sections
Each section of the template must be completed to the extent possible for the Project
Approval Gate being requested. It is also understood that in certain situations there might be
checklist items which for various reasons might not be possible to be compiled. In this case,
the form should be filled in with the following acronyms according to the prescribed scenario.
Acronym
Description
Scenario
TBD
To Be Determined
Information requested in a particular section is
not yet available or known at the time of
completion of the section. In such a case,
when the subsequent section of the document
is completed, the information that was
previously unavailable must be provided.
NDI
Non Disclosed Information
Information being requested cannot be
disclosed. Typical reasons could include:
o Contractual obligations/ limitations;
o Intellectual
Property
Rights
(Copyright, Patent)
o other reason
Note: a valid reason for not providing the information must
be clearly stated.
NR
Not relevant
Information being requested is not relevant to
the solution being assessed.

Basic Profile Section: This section of the document is required to be submitted,
reviewed, and approved by TSG, prior to receiving Gate 1 (Project Initiation) Project
Approval.

Preliminary System Design Section: This section of the document is required to be
submitted, reviewed, and approved by TSG, prior to receiving Gate 2
(Planning/Design) Project Approval.

Detailed System Design Section: This section of the document is required to be
submitted, reviewed, and approved by TSG, prior to completing Gate 3 (Execute and
Build) Project Approval. Normally, this documentation would be submitted as soon as
the Detail System Design has been completed.

Update to Detail System Design Section: An update to the detail design is
required to be submitted, reviewed, and approved by TSG, prior to receiving Gate 3
(Implementation) Project Approval. Any changes to the system design based on pilot
testing must be incorporated. Once this approval has been issued, the
Implementation phase may begin.
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 4 of 34
Preliminary System Design
Section
Basic Solution
Profile Section
Gate 1:
Project Initiation Review
Detailed System
Design Sector
Gate 2 :
Planning / Design Review
Gate 3:
Execution/ Build/ Pilot Review
(Pre-Implementation)
Update Solution
Architecture
Solution Assessment Gates
1.2
TSG Offers Assistance to Public Sector Organisation
One of the primary services that TSG offers to PSOs is system design review and assistance.
Involving TSG as early as possible in the project (e.g. during RFP creation or system design)
is a key factor to the overall success of a project. This type of early involvement helps to
ensure that the project complies with the necessary standards and policies. It also facilitates
Project Approval. If you would like to request TSG assistance, or have any questions
concerning the completion of this document, please send an email on eau.mita@gov.mt
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 5 of 34
2. System Design Change Log
Any moderate or significant changes to the system design must be resubmitted to TSG
for review and approval prior to making any actual implementation change(s). In most cases,
the review and approval of any changes would be performed internally within TSG.
Notes:
1. Use of a word processing automated change tracking feature is required when
resubmitting this document in order to simplify the review and approval process. Once a
version of the document has been approved, then that version of the document should be
saved for archival purposes. Prior to submitting a new version of the document, all prior
tracked changes should be accepted. This process for resubmission can then be
repeated as many times as necessary until the final approval has been issued.
2. Failure to resubmit changes for review and approval could result in a
recommendation by TSG that the project approval status be reconsidered. If there are
any questions as to whether or not a change is substantive enough to warrant review
and approval, please send an email on eau.mita@gov.mt for clarification.
3. Maintain a summary of changes in the table below.
Change Log Summary – Description
(For instructional purposes examples have been
provided)
Version
Date
Example: New System:
MyPassport- This system includes the introduction of
biometric passports.
1.0
13/02/2010
Example: Upgrade:
MyPassport- Added the use of a new web service.
2.0
30/03/2010
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 6 of 34
3. Gate 1: Basic Solution Profile
The Basic Solution Profile Section has been designed to capture only the most essential
information required for the Initial Project Approval.
3.1
High Level Business Scope of Solution
Business Context Checklist
Business Description
(Provide basic information on the purpose of the solution and what business areas the solution must cover. Clearly highlighting Benefits,
Assumptions , Dependencies, Risks)
EU Initiative / Obligations
__ No __ Yes
 Which EU law / directive / initiative mandate the creation of the solution?
Mission Criticality (in the
context of Government’s
business)

Which local law / directive mandate the creation of a solution?

What are the repercussions of not implementing the solution?
(Example: Penalties, Disruption to Government’s ICT / Business Strategy. Clearly provide the
necessary documentation to substantiate your case)

By when does the solution need to be live / available for use?
(Provide reason why)
Monetary Value / Budget
Allocated
Capital Expenditure (CAPEX)
_______(Euros)
(Such as: Procurement , Deployment etc)
Operational Expenditure (OPEX)
_______(Euros)
(Such as: Maintenance & Support, Recurring License Costs etc)
Kindly also highlight Budget Sources funding the solution:
NOTE: If breakdown of the above values is available, kindly attach with the
submission.
Solution Scope
___ International
(inter-governmental- Solution which will be shared or is common amongst governments; implemented
across EU member states)
___ Government Wide
(Interdepartmental - Solution which will be shared or is common amongst local Government
departments)
___ Local
(Departmental - Solution which will be only used by the specific Government department)
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 7 of 34
3.2
Basic System Checklist
Disclaimer: Any technologies listed below have been provided solely for convenience,
the information provided is not intended to be exhaustive nor does it indicate product
endorsement by TSG.
Conceptual System Checklist
Responses - Select all that apply
Project Type
__ New System __ Upgrade System
Delivery of Functionality
__ Functionality delivered over time
__ Functionality delivered all at once
System Interactions
__ Government to Citizen (G2C)
Services offered to the Public
__ Government to Business (G2B)
Services offered to the third party organizations which are not controlled by the Government
__ Government to Government (G2G)
Services intended to be used by Ministries, Government departments and/or entities
__ Government to Other Government (G2OG)
Services that will be used by other Governments, such as Other EU member states
List/ Verify that the solution adheres to the ICT
Policies/Directives
ICT Policies and Directive can be found at http://ictpolicies.gov.mt.
Highlight any deviations (providing detailed description) to the Policies/
Directives found in the above URL.
Such as:
o
GMICT X 0071:2010 Adopted Specifications
o
CIMU S0051 Website Standard
o
CIMU P 0012:2003 Third party Web hosting
services Policy
Estimated Total Number of Customers 
Total: __________
By Audience:
Citizen: ______ Employee: _____ Business:______ Other:______
Note: For systems were functionality will be delivered over time specify amounts by
implementation phase.

The quoted figures should serve as guidelines and should be provided on an estimate basis. The figures are
also subjective to the type of application (i.e. whether the solution is a client server application or web based
application).
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 8 of 34
Conceptual System Checklist
Responses - Select all that apply
Estimated Total Number of Concurrent
Customers 
Total: _________
By Audience:
Citizen: ______ Employee: _____ Business:______ Other:______
Note: For systems were functionality will be delivered over time specify amounts by
implementation phase.
Estimated Annual Customer Growth Rate
Percentage: _________
By Audience:
Citizen: ______ Employee: _____ Business:______ Other:______
Note: For modular delivery specify amounts by implementation phase.
Electronic Form
Performance Requirements Section
Please list down any performance requirements related to the following
classes of performance clearly highlighting the scenario, the value and unit
of measurement, method of measurement.
 response times (how fast the system handle individual requests, what
a real user would experience)
 throughput (how many requests the system can handle)
 concurrency (how many users or threads work simultaneously)
Note: Fill as deemed necessary
Production Hours of Operation
__ Citizen
__ Normal Business Hours (e.g. 8:00 am to 5:00 pm)
__ Extended Business Hours (specify): _______________
__ 24 X 7
__ Employee
__ Normal Business Hours (e.g. 8:00 am to 5:00 pm)
__ Extended Business Hours (specify): _______________
__ 24 X 7
__ Government/Business Partner(s)
__ Normal Business Hours (e.g. 8:00 am to 5:00 pm)
__ Extended Business Hours (specify): _______________
__ 24 X 7
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 9 of 34
Conceptual System Checklist
Responses - Select all that apply
Production Availability Expectations on a
monthly basis
Kindly highlight any peaks and troughs of the service being rendered?
e.g. Every end of the month there is a peak due to the license renewal
process.
What are the repercussions if the system fails?
e.g. The PSO needs to extend the time window for receiving license
renewals which results in an increase in cost.
Uptime
__ 99
(2 Nines)
__ 99.5
__ 99.9 (3 Nines)
__ 99.99 (4 Nines)
__ 99.999 (5 Nines)
__ Other (specify):
=> Downtime/month (i.e. unplanned)
=> 7h 30m
=> 4h 45m
=> 1h 45m
=> 5m
=> 30s
Scheduled Downtime:
__ Minutes (specify amount):________
__ Hours (specify amount):__________
Service Restoration:
__ Minutes (specify amount):________
__ Hours (specify amount):__________
MTBF: (Mean Time Between Failure)
__ Minutes (specify amount):________
__ Hours (specify amount):__________
Note: Please indicate how the SLA shall be monitored
Application Backup Requirements
Full Backup:
__ Daily __ Weekly
Incremental Backup:
__ Hourly __ Daily __ Weekly
Application Recovery Time
__ Minutes (specify amount):________
__ Hours (specify amount):__________
Solution Delivery Model / Business Model
__ as a Service (subscription based)
Note: Please refer to Cloud Services check list https://www.mita.gov.mt/MediaCenter/PDFs/2_SC29-REP-Cloud-Common-Assessment-andConsiderations-v1.0.pdf)
__ Traditional
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 10 of 34
Conceptual System Checklist
Responses - Select all that apply
Target Hosting Environment
__ Shared eGovernment Web Hosting Environment managed & supported
by MITA - This applies for existing systems only i.e. solution updates/
upgrades
__ Dedicated Environment at the Government Data Centers managed by
MITA – This applies for existing systems only i.e. solution updates/
upgrades. Service Hosting Catalogue TYPE 2 - refer to service
hosting catalogue (https://www.mita.gov.mt/MediaCenter/PDFs/1_IMSGDL-ServiceHostingCatalogue-v1.0.pdf)
__ Dedicated Environment at the Government Data Centers managed by
3rd parties (in line with the PRE principles)
__ Computing resources provided by MITA - Service Hosting
Catalogue TYPE 1B - refer to service hosting catalogue
(https://www.mita.gov.mt/MediaCenter/PDFs/1_IMS-GDLServiceHostingCatalogue-v1.0.pdf)
__ Computing resources not provided by MITA - Service Hosting
Catalogue TYPE 1A - refer to service hosting catalogue
(https://www.mita.gov.mt/MediaCenter/PDFs/1_IMS-GDLServiceHostingCatalogue-v1.0.pdf)
rd
3 Party Supplier Organization:____________
NOTE: This is subject to approval i.e. involving business negotiations and
appropriate discussions with the respective stakeholders
__ Hosting managed & supported at 3rd parties
__Shared
__Dedicated
Organization providing the hosting:_______________
Organization providing the management & support:_______________
Country where the data shall be residing:________________
Country from where the service shall be rendered:________________
NOTE: If more than one hosting mode is selected please supply more
information about the role of each hosting layer
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 11 of 34
Conceptual System Checklist
Responses - Select all that apply
System Usage of Government Shared
Services
__ myBills
Shared Service handling online government payments.
__ myForms
Shared Service for creating electronic forms and the respective workflows
for the delivery of citizen centric eServices
__ myAlerts/ mGov
Shared alerting services used to deliver Short Message Services (SMS)
and email notifications.
__ eID
A shared service which allows citizens and businesses to identify
themselves via the government’s Web portal or telephone contact centre to
securely access any number of available e-Services, regardless of which
organization provides the service.
__ CDR
Shared Service providing access to Corporate Data.
__ Corporate identity
A Shared Service for the provision of Identity to the Public Administration.
Kindly highlight any usage peaks of the service/s being consumed
NOTE: For Gate 2 approval the respective service contract
that includes the respective service consumption mechanism
must be included. (Service Contract Template Appendix A)
System Usage of 3rd Party Service
Identify and list any interactions required with 3rd party
services in the table below:
Service Name
Service Provider
NOTE: For Gate 2 approval the respective service contract
that includes the respective service consumption mechanism
must be included. (Service Contract Template Appendix A)
3.3
Functional System Description
Provide a diagram (or diagrams) with corresponding narrative that depicts the functional
aspects of the application. Corresponding narrative that describes each major functional area
of the application must also be supplied. Describe how the system will be used and operated.
Describe both the type of users of the system as well as any business interfaces that may be
necessary.
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 12 of 34
Note: The diagram below has been provided for illustrative purposes only. PSOs
should delete the diagram provided and supply information specific to the application
requesting approval.
Financial Management Application
(Functional Design)
Employees
Purchasing
Accounts
Payable
Accounts
Receivable
Fixed
Assets
General Ledger
Business
Direct
Deposits
Bank
Reconciliation
Billing
Shipping
Internal
Agency
Interfaces
(e.g Payroll,
And HR)
External
Agency
Interfaces
(Specify)
Reporting
Citizens
Note: Narrative describing the functional design of the application must be provided
immediately following the diagram(s).
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 13 of 34
1..*
Deposit
1..*
1
«uses»
Withdrawal
1..*
Transaction
1..*
Transfer
«uses»
1
1..*
Bank Database
Inquiry
1..*
«uses»
Customer
Identification
Bank Contact
Request
Customer
1..*
1
1..*
Stock
Consultation
«extends»
«uses»
Bank Employee (Front office)
Office
Consultation
«uses»
Stock
Analysis
Stock Order
Management
Agent
Stock Order
Collection
«uses»
1..*
Stock Credit
«uses»
1
Stock Business
1..*
Bank Employee (Back office)
«uses»
Stock Transfer
«uses»
Stock Debit
Find Business
Cancel Business
Approve Stock
Business
Find Stock
1..*
«uses»
1
«uses»
Manage Stocks
1..*
Create New
Stock Paper
«uses»
Stock Account Admin (Back office)
«uses»
Modify Stock
Lock Stock
Example:
Transaction Use Case
The transaction use case starts when the customer chooses a transaction type from a menu
of options. The customer will be asked to furnish appropriate details (e.g. account(s) involved
and amount). The transaction will then be sent to the bank, along with information from the
customer's card and the PIN the customer entered.
If the bank approves the transaction, any steps needed to complete the transaction (e.g.
dispensing cash or accepting an envelope) will be performed, and then a receipt will be
printed. Subsequently the customer will be asked whether he/she wishes to do another
transaction.
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 14 of 34
If the bank reports that the customer's PIN is invalid, the Invalid PIN extension will be
performed and then an attempt will be made to continue the transaction. If the customer's
card is retained due to too many invalid PINs, the transaction will be aborted, and the
customer will not be offered the option of doing another.
If a transaction is cancelled by the customer, or fails for any reason other than repeated
entries of an invalid PIN, a screen will be displayed informing the customer of the reason for
the failure of the transaction, and then the customer will be offered the opportunity to do
another.
The customer may cancel a transaction by pressing the Cancel key as described for each
individual type of transaction below. All messages to the bank and responses back are
recorded in the ATM's log.
Withdrawal Transaction Use Case
A withdrawal transaction asks the customer to choose a type of account to withdraw from
(e.g. checking) from a menu of possible accounts, and to choose a Euro amount from a menu
of possible amounts. The system verifies that it has sufficient money on hand to satisfy the
request before sending the transaction to the bank. (If not, the customer is informed and
asked to enter a different amount.) If the transaction is approved by the bank, the appropriate
amount of cash is dispensed by the machine before it issues a receipt. (The dispensing of
cash is also recorded in the ATM's log.)
A withdrawal transaction can be cancelled by the customer pressing the Cancel key any time
prior to choosing the Euro amount.
N.B. The above example is showing only a small part of the functionality of the above use
case diagram. This section should include a description of the high level functionality
illustrated in the above diagram.
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 15 of 34
3.4
Conceptual System Design Description
Provide a diagram (or diagrams) with corresponding narrative that depicts an accurate
description of the conceptual design for the entire application. The design must document
how each of the requirements specified in the functional design will be conceptually
accomplished. The conceptual design must align with the Principles, Practices, and
Standards
that
are
published
in
the
http://ictpolicies.gov.mt
and
https://www.mita.gov.mt/page.aspx?pageid=228 portals respectively.
Note: The diagram below has been provided for illustrative purposes only. PSOs
should delete the diagram provided and supply information specific to the application
requesting approval.
Financial Management Application – Conceptual Design
Hardened Internal
Network
Web
Server
Firewall 3
Internal Network
Firewall 2
Citizen
DMZ
Firewall 1
Internet
Employee
Application
Server
Database
Server
Firewall 3
Single
(or Reduced)
Sign-on
Service
EDI
Messaging
Middleware
External
Business
Partner
External
Agency
Application
Credit Card
Processing
Service
Note: Narrative describing the conceptual design of the application must be provided
immediately following the diagram(s).
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 16 of 34
4. Gate 2: Preliminary System Design
The Preliminary System Design Section has been designed to capture only the most essential
information required to obtain Preliminary Design approval. While the items listed are not
intended to be an exhaustive list of the possible technologies that may be utilized in the
implementation of an application, it does reflect some of the more common choices as well as
important items that should be considered during the design phase.
4.1
Preliminary System Checklist
Disclaimer: Any technologies listed below have been provided solely for convenience,
the information provided is not intended to be exhaustive nor does it indicate product
endorsement by TSG.
Preliminary System Checklist
Responses – Select all that apply
Development Approach
__ Commercial Off The Shelf (COTS )
__ Free Libre‘ Open Source Software (FLOSS)
__ Commercial Open Source
__ Custom / Bespoke
Note: Customizations to COTS or FLOSS solutions must be limited to 10% and be fully
supported in future releases or versions
Software License Framework
______________
NOTE: Specify License Framework. Such as GPLv3, EUPL, LGPL, BSD, etc.
Web Based
__ Yes
__ No Virtualizable: Yes____ No ____
NOTE: For non web based solutions indicate if the desktop application can be abstracted via
virtualization.
Architectural Approach
__ SOA __ 3/N Tier __ Other (specify):
Processing Type
__ OLTP __ OLAP __ Other (specify):
Development Platform
__ J2EE __ .NET __ Other (specify):
_______Version
Architectural Framework(s)
__ STRUTS __ JATO __ JSF
__ Other (specify):
Architectural Pattern(s)
__ MVC __ Factory __ Controller __ Data Access Object
__ Other (specify):
Application Communication Technologies
(Within the Solution Domain)
Service Interface:
__ Web Services (HTTP, XML, SOAP, WSDL, UDDI)
__ Public Facing
__ Internal Facing
__ Messaging / Message Queuing
Platform Specific:
__ .NET Remoting
__ EJB/RMI – IIOP
__ Other (specify):
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 17 of 34
Preliminary System Checklist
Responses – Select all that apply
System Integration Technologies
(Both for service provisioning and service
consumption)
__ XML __ Web Services __ Messaging __ EDI __ CORBA
__ IIOP __ Adaptors __ Secure FTP
__ Proprietary API via __________
__ Other (specify):
Note: Kindly fill in the Service Contract/ Adapter Definition
template (Refer to Appendix A), to include any additional
information with respect to the service/s being offered through the
solution.
Security Technologies
Secure Authentication:
e.g. Solution Integrated authentication using login and password
stored in the database
e.g. Solution Integrated authentication using login and password via
database accounts stored in the RDBMS
e.g. Solution Integrated authentication using certificate based
authentication via accounts stored in the local directory service.
e.g. Providing local authentication to 3rd parties via claims based
authentication using WS-Federation Passive Requestor Profile
e.g. Using eID or the Government Public Administration Identity
Services
Secure transport :
e.g. SSL/TLS, IPSEC
Secure Storage:
e.g. Data Encryption - __ Column __ Row __ Table __ Database
using AES encryption
e.g. Cookie Encryption using AES encryption
__ Other Scenario where data is persisted on in transit (specify):
Provide the security technologies which have been used in the mentioned
contexts. The government adopted specifications related to Encryption
and signing algorithms can be found on http://ictpolicies.gov.mt/
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 18 of 34
4.2
Development Quality Description
The Development Quality Description section has been designed to capture how quality
aspects such as portability, maintainability, extensibility, supportability and re-usability shall
be reflected in the software part of the proposed solution.
Portability
The ability for a solution to be migrated/ installed on a different environment other then the original one, without the need of
any code changes.
Maintainability
Ease of extending the solution functionality, fixing of errors etc.
Extensibility
The ability for the solution to be extended with ease and with minor modifications (future proof solution).
Supportability
The ability for the solution to be more efficient in terms of product maintainability thus reducing operational costs (installation,
configuration and monitoring) maintaining business continuity.
Re-usability
The ability to use modified or unmodified solution components (subroutines etc.) in other solutions.
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 19 of 34
4.3
Preliminary System Design Description
Provide a diagram (or diagrams) with corresponding narrative that depicts an accurate and
detailed description of the preliminary design for the entire application. The design must
document how each of the requirements specified in the conceptual design will be logically
accomplished. The preliminary design must align with the Principles, Practices, and
Standards
that
are
published
in
the
http://ictpolicies.gov.mt
and
https://www.mita.gov.mt/page.aspx?pageid=228 portals respectively.
At this point, properties such as scalability, availability, and security posture should be
reflected. External network connection speeds (for both the citizen and employee) should be
documented. The supporting application should perform at acceptable levels when utilizing
lowest common access speeds. Specify any known hardware and software details (brand,
model, version, etc) for clients, servers, and other network infrastructure; programming
languages selected, and deployment location (i.e. server location where code is deployed).
Interfaces must be identified.
Note: The diagram below has been provided for illustrative purposes only. PSOs should
delete the diagram provided and supply information specific to the application requesting
approval.
SSL
Remote
Access
Employees
(N=50)
Field
Employees
(N=100)
VPN
Web
Server
VPN
VPN
Employee
Desktop
(N=300)
Zone 3 Firewall
VPN
Zone 3
(Hardened Internal
Network)
Zone 2
(Internal Network)
Zone 2 Firewall
Citizen
(5000
Transactions
Per day
Transaction
Zone
(Hardened DMZ)
Load Balancer
Zone 0/1
Internet
Transaction Zone Firewall
Line of Business Application – Logical Design
Zone 3 Firewall
WAN
EDI
Service
Broker
Common Payment
Service
(CC and ACH)
External
Agency
Application
Credit
Card
Authorization
Dedicated Circuit
External
Business
Partner
DB
Server
(Mirror)
VPN
VPN
Identity
Access
Management
System
Appl.
Server
(Cluster)
VPN
Note: Narrative describing the preliminary design of the application must be provided
immediately following the diagram(s).
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 20 of 34
4.4
System Architecture Quality Description
The Service Quality Description section has been designed to capture how quality aspects
such as Performance/Throughput, Security, Integrity, Reliability, Availability, Scalability,
Manageability, Serviceability and Recoverability shall be reflected in the proposed solution.
Fill in the applicable section hence reflecting how the solution shall be delivered.
Performance/Throughput



Response times: how fast the system handles individual requests in terms of user experience.
Throughput: how many requests the system can handle.
Concurrency: how many users or threads work simultaneously
List down the mechanism/s that the solution uses to achieve/ support the above mentioned factors where applicable
Security

Authentication: The substantiation of the identity of a person or entity related to the system in some way.

Authorization: The definition and enforcement of permitted capabilities for a person or entity whose identity has been
established.

Audit: The ability to provide forensic data attesting that the system was used in accordance with stated security policies.

Assurance: The ability to test and prove that the system has the security attributes required to uphold the stated
security policies.

Asset Protection: The protection of information assets from loss or unintended disclosure, and resources from
unauthorized and unintended use.

Administration: The ability to add and change security policies, add or change how policies are implemented in the
system, and add or change the persons or entities related to the system.
List down the mechanism/s that the solution uses to achieve/ support the above mentioned factors
Integrity
The capability for an application to bring data or a function from one application program together with that of another
application program.
List down the mechanism/s that the solution uses to achieve/ support the above mentioned factors
Reliability
The ability for a system to be aware of the hardware and software components to determine where and why failure is high
and consequently is able to apply actions in order to reduce failure.
List down the mechanism/s that the solution uses to achieve/ support the above mentioned factors
Availability
The ability of the system to function without service interruption or depletion despite abnormal or malicious events.
List down the mechanism/s that the solution uses to achieve/ support the above mentioned factors
Scalability
A property of a solution or process, which indicates its ability to either handle growing amounts of work (in terms of work load
capacity – computational power etc.) in a graceful manner or the ability and ease of enhancing the solution to handle new
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 21 of 34
requirements.
List down the mechanism/s that the solution uses to achieve/ support the above mentioned factors
Manageability
The building blocks of manageability can be viewed as
Deployable: Solution deployment (moving or replication of information or binaries) aspects.
Diagnosable: Ability for Solution to provide auditing functionality to enable easy tracing and diagnosis of errors/ issues .
Disaster-recoverable: The ability for the solution to recover from run-time crashes; considerations should also include data
recovery aspects.
List down the mechanism/s that the solution uses to achieve/ support the above mentioned factors
Serviceability
The ease and extent of changes that can be affected without interrupting the application and the environment, consequently
affecting availability.
List down the mechanism/s that the solution uses to achieve/ support the above mentioned factors
Recoverability
The ability towards a fast, easy, and reliable recovery of business data from virtually any disruption or event.
List down the mechanism/s that the solution uses to achieve/ support the above mentioned factors
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 22 of 34
5. Gate 3: Detail System Design
The Detail System Design Section has been designed to capture only the most essential
information required at this point to obtain Detailed Design approval. While the items listed
are not intended to be an exhaustive list of the possible technologies that may be utilized in
the implementation of an application, it does reflect some of the more common choices as
well as important items that should be considered during the design phase.
5.1
Detail System Design Checklist
Disclaimer: Any technologies listed below have been provided solely for convenience,
the information provided is not intended to be exhaustive nor does it indicate product
endorsement by TSG.
Detail System Checklist
Responses – Select all that apply
Client Platform Information
__ Standard Desktop
Refer to Desktop Software and Configuration standard - GMICT S
0002:2009; Desktop Hardware standard - GMICT S 0001:2007
__ Non Standard Desktop
o Type (PDA, Smartphone etc.) __________
o OS (Linux, Android, Palm etc.) __________
OS Version __________
Please fill in the above (Non Standard Desktop) information, if platform
differs from the standard Government Hardware and Desktop
Configuration.
Client Footprint by Platform
Specify size of footprint in KB or MB: __________
This information will serve as an indication in case the application needs to
be virtualised/ streamed.
Client Connection Speed
Specify bandwidth in kbps or mbps:
Minimum: _____
Recommended: ________
Considerations depend on the client platform type including whether the
connection is wired or wireless.
Client Richness
__ Browser Based
__ Rich Internet (AJAX, Flash etc.)
__ Rich Client
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 23 of 34
Detail System Checklist
Responses – Select all that apply
Browser Support
The solution must be compatible and support the browser/s identified in the
Desktop Software and Configuration standard - GMICT S 0002:2009).
__ Other (specify product and versions):
Presentation - Client Side Languages
__ HTML __ DHTML __ XML __ XHTML
__ VB.NET __C# __ Flash
__ Java ApplTSG __ Java
__ JVM (specify details):
__ JavaScript __ VBScript
__ C++
__ Other (specify):
Application State
__ Cookies:
__ Non-Persistent Cookies
__ Persistent Cookies
__ Session Ids
__ State Stored in Hidden Fields
__ Other (specify):
Web Server Location
__ Public Facing __ Internal Facing
Web Server Operating System
__ Windows __ Linux __ Unix __ Other (specify):
Specify Version:
Web Server Software
__ Apache __ Microsoft __ Sun __ Oracle__ Other (specify):
Specify Edition and Version:
Load Balanced: __ Yes __ No
__ Other (specify):
Web Server - High Availability
Web Server - Specifications
Rollout Configuration:
Number of Servers: __ CPUs/Server: __ CPU Type: _________
CPU Speed: _____ Amount of RAM: ____
Processor Architecture: __ 64 Bit __ 32 Bit
Maximum Configuration:
Number of Servers: __ CPUs/Server: __ CPU Type: __________
CPU Speed: _____ Amount of RAM: ____
For PRE hosting; additional information is required (refer to PRE
Documentation https://www.mita.gov.mt/MediaCenter/PDFs/3_TSG-REPPrivateRuntimeEnvironment_Public-v2.0.pdf)
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 24 of 34
Detail System Checklist
Responses – Select all that apply
Presentation – Server Side Languages
__ ASP.NET __ VB.NET __C#
__ JSP __ Servlets __ Java
__ JVM (specify details):
__ Server Side Includes (SSI)
__ C++
__ Other (specify):
Application Server Operating System
__ Windows __ Linux __ Unix __ Other (specify):
Specify Version:
Application Server Software
__ Microsoft __ IBM __ Sun __ Oracle __ BEA __ Other (specify):
Specify Edition and Version:
Application Server – High Availability
RAID Supported: __ Yes __ No
SAN Supported: __ Yes __ No
Mirroring Supported: __ Yes __ No
Clustering Supported: __ Yes __ No
Grid/On Demand Supported: __ Yes __ No
__ Other (specify):
Application Server - Specifications
Rollout Configuration:
Number of Servers: __ CPUs/Server: __ CPU Type: _________
CPU Speed: _____ Amount of RAM: ____
Processor Architecture: __ 64 Bit __ 32 Bit
Maximum Configuration:
Number of Servers: __ CPUs/Server: __ CPU Type: __________
CPU Speed: _____ Amount of RAM: ____
For PRE hosting; additional information is required (refer to PRE
Documentation https://www.mita.gov.mt/MediaCenter/PDFs/3_TSG-REPPrivateRuntimeEnvironment_Public-v2.0.pdf)
Virtualization Technologies
___ Server Virtualization: Vendor:__________
___ Storage Virtualization: Vendor:__________
___ Application Virtualization: Vendor:__________
___ VDI: Vendor:__________
___ Other: Vendor:__________
Business Rule – Application Languages
__ VB.NET __C#
__ Java (J2SE) __ Java/EJB (J2EE)
__ JVM (specify details):
__ C++
__ Other (specify):
Database Server Operating System
__ Windows __ Linux __ Unix __ Other (specify):
Specify Version:
Database Server Software
__ Microsoft __ IBM __ Oracle __ Other (specify):
Specify Version:
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 25 of 34
Detail System Checklist
Responses – Select all that apply
Database Server – High Availability
RAID Supported: __ Yes __ No
SAN Supported: __ Yes __ No
Mirroring Supported: __ Yes __ No
Clustering Supported: __ Yes __ No
Grid/On Demand Supported: __ Yes __ No
___ Other (specify):
Database Server - Specifications
Rollout Configuration:
Number of Servers: __ CPUs/Server: __ CPU Type: _________
CPU Speed: _____ Amount of RAM: ____
Processor Architecture: __ 64 Bit __ 32 Bit
Maximum Configuration:
Number of Servers: __ CPUs/Server: __ CPU Type: __________
CPU Speed: _____ Amount of RAM: ____
For PRE hosting; additional information is required (refer to PRE
Documentation https://www.mita.gov.mt/MediaCenter/PDFs/3_TSG-REPPrivateRuntimeEnvironment_Public-v2.0.pdf)
Data Access – Connectivity Methods
__ ADO.NET __ ODBC __ OLE/DB
__ JDBC __ JDO
__ DB2 Connect
__ Other (specify):
SQL Languages
__ T/SQL __ PL/SQL __ Other (specify):
Use of SQL ANSI 92/99 (and appropriate successors) compliant constructs
Stored Procedures Utilization
__ No
__ Yes
__ Data Access only
__ Business Rules and Data Access
Note: The implementation of propriety procedural logic (i.e. vendor specific
SQL syntax / feature usage hence non SQL ANSI Compliant) should be
strictly avoided unless there is a formally substantiated need to do
otherwise. This excludes the specific application of back-office, batch type
processes which are isolated to limited instances.
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 26 of 34
5.2
Detail System Design Description
Provide a diagram (or diagrams) with corresponding narrative with that depicts an accurate,
detailed, and complete description of the detail design for the entire system. The design must
document how each of the requirements specified in the preliminary design will be physically
accomplished. The detailed design must align with the Principles, Practices, and Standards
that
are
published
in
the
http://ictpolicies.gov.mt
and
https://www.mita.gov.mt/page.aspx?pageid=228 portals respectively.
Almost all details should be known at this point in the design process, including specific
hardware related information utilized by the hosting service provider. Design objectives such
as Reliability, Availability, Scalability, Secureability, Interoperability, and use of Common
Infrastructure should be adequately reflected in the physical design. All aspects of the
application, network, security, and integration architecture, as well as any other pertinent uses
of technology to solve specific business requirements (e.g. document imaging, channel
support for the numerous client form factors such as smart phone, PDA etc) should be
documented.
5.2.1 Detail System Design – Infrastructure Architecture
Note: The diagram below has been provided for illustrative purposes only. PSOs
should delete the diagram provided and supply information specific to the application
requesting approval.
XYZ Solution
Physical Design
INTERNET
ISP
Dial-in
ADSL
T1
T3
OC3
T1 Line
Customers and / or Citzens
Transaction Zone
Screened Subnet
Private Address
Border Router
ZONE 2
Management Subnet
(Private Address)
Screened Subnet(192.168.0.1)
Gigabit
Reverse Proxy
& Load Balancer
NIDS
External Hardware
Firewall Gateway
With NAT and 3 Interfaces
Web Server
Web Server
NIDS
Mail Relay
With Anti-Spam
DNS
Admin
Console
N=1
Switch
ZONE 3
Application Subnet
(Private Address)
Switch
Internal Network (192.168.0.1)
Gigabit
Switch
ZONE 2
Shared Services Subnet
(Private Address)
Employee
/ Clients
N = 10
ZONE 2
Client Subnet
(Private Address)
Internal Hardware
Firewall with 2 Interfaces
Mail Server
& A/V
DNS
Solution Architecture Document
File & Print
Server
Switch
NIDS
App Server
With IDS
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
DB Server
with IDS
NIDS
Page 27 of 34
Note: Narrative describing the detail design of the application must be provided
immediately following the diagram(s).
5.2.2 Computing Resources Required
5.2.2.1 Type 1A Hosting – Hardware Provided By Solution Provider
Data Centre Facilities
Query
Number of Physical Servers
Response
Rack Space required (in rack Height Units)
Air Flow Direction (e.g. Front-bottom-up, etc)
Total Heat Dissipation (Btu/Hr)
Total Power Consumption (kVA)
Operating Temperature (degrees Celsius)
5.2.2.2 Type 1B Hosting – Computing Resources Provided by MITA
Virtualised Environment Requirement
Query
Response
Query for each Guest
Response
Number of Guests
CPU (GHZ)
RAM (GB)
Hard disk space (GB)
Number of Network interfaces
Bandwidth needed for each interface (KBps)
Frequency of backups(daily/weekly/monthly)
Can server be shut down during the backup
process? (Yes/No)
Operating System (Windows Linux x64/x86)
Database Management Server (e.g. SQL;
Oracle( if any)
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 28 of 34
5.2.3 Network Access Requirement (Type 1A, Type 1B and Type 2 Hosting)
Access Required for each
Guest
Access
required
from
Access
required
to
TCP/UDP
port
Access required both ways
Anti Virus (updates of AV)
Netbios
OS Updates
DNS
Remote support (RDP/SSH)
Internet Access
HTTP
HTTPS
SMTP
POP3
IMAP
IMAPS
5.2.4 Detail System Design – Application Architecture
Provide a detailed system design reflecting the Presentation Layer, Business Layer and Data
Access Layer.
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 29 of 34
6. Technical Architecture Domains
Please provide any significant architectural information (that has not been previously
provided) for this application. Areas of particular interest include use of new technologies,
leveraging existing infrastructure, use of new or emerging technologies, and any deviations
from the Agency Architecture Principles, Standards, or Best Practices.
6.1
Network Domain:
[Specify any additional information]
6.2
Application Domain:
[Specify any additional information]
6.3
Data Domain:
[Specify any additional information]
6.4
Systems Integration Domain:
[Specify any additional information]
6.5
Groupware Domain:
[Specify any additional information]
6.6
Platform Domain:
[Specify any additional information]
6.7
Enterprise Management Domain:
[Specify any additional information]
6.8
Security Domain:
[Specify any additional information]
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 30 of 34
7. Appendix A – Service Contract/ Adapter Definition
Section 1 - Functional
1. Consumption Information
How is this service consumed?
The services provides an SMTP relay from the consumer to gov.mt domains and other domains registered through
ICANN domain registration services, including subdomains and have the appropriate Mail Exchanger DNS
Mechanisms in place.
The transmission of data through the consumption of this service is not secured through the use of TLS/SSL
certificates, therefore it is the responsibility of the consumer to encrypt data.
User authentication for each connection is not required.
Sender domain must be valid and defined by MITA SMD.
Access control is configured through Firewalls at the Segregated Environment Edge.
Each message is scanned against a list of viruses and malicious content.
2. Interfaces provided
Technical information on the accessibility of the Interfaces provided
3. List of Functionality
List of functionality that is available within the interfaces defined in Section 3 Property 2
4. Standards
The following is a table with a list of standards relevant to the provision of this service.
Standard
Information
SMTP
http://tools.ietf.org/html/rfc5321
TLS/SSL
http://tools.ietf.org/html/rfc5246
DNS
http://www.ietf.org/rfc/rfc1035.txt
SNMP
http://www.snmp.com/protocol/
5. Location of Documentation
The physical/virtual location of the technical design, including interfacing documentation and architecture blueprint
of this adapter
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 31 of 34
Section 2 - Other terms
1. Transactional
How does this adapter support transaction, provide for compensation, or does not provide transactional facility at
all
2. Service Level Terms and Conditions
The Service Level Agreements (SLA) and other terms and conditions related to the consumption of this service
The adapter is monitored through MITA central monitoring services via SNMP. The uptime availability is available
through the MITA hosting services. Each consumer should not send more than 10 mails per second when
messages do not exceed 10 Kilobytes each.
Consumers abusing the system will be disconnected without notice.
3. Quality of Service
What are the quality checks that were carried out during the design, development and deployment of this adapter?
This adapter was designed according to IETF specifications and best practices. It is based on IP protocols to
ensure scalability and re-usability. The implementation is controlled by the MITA Change Management process.
4. Auditing Information
What are the auditing mechanisms in place, if available at all, including the data elements that are recorded for
auditing purposes? Include the Data Protection measures that are in place according to GMICT policy and
Legislation
5. Defined processes
List the processes that are available in order to apply for usage, disconnection or modifications of this adapter, as
well as processes related to the consumer accessibility to the adapter.
Requests for consumption of this adapter are controlled by MITA SMD. A change request is required to open port
25 from the Private Runtime Environment to the service as defined under interfaces.
Requests for access to the adapter are identified through the architecture blueprint to be presented according to
Architecture Blueprint requirements available at https://www.mita.gov.mt/page.aspx?pageid=228. Project
Manager is responsible to trigger change management process.
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 32 of 34
Section 3 - Responsibilities
This section provides information about the roles and persons responsible for the provision of
the service through this adapter.
Responsible Role
Organisation-Team
Accountable Role
Organisation-Team
Consultative Role
Organisation-Team
Informative Role
Organisation-Team
Solution Architecture Document
Template Version: 1.0
Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
Page 33 of 34