Solution Architecture: Technical Document

< 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> Ministry / Department / <Entity name>

Company
Submission Contact Title: <CTO / CIO / Officer / IMU / Supplier>
Submission Contact Details: <email> / <telephone> / <mobile>
Project Completion Date: <Date>
Supplier: <Supplier name> Supplier Contact <Supplier contact

Person:
person>
Supplier Contact Details: <email> / <telephone> / <mobile>
Client Name: <Client name> Ministry / Department / <Entity name>

Company
Client Contact Details: <email> / <telephone> / <mobile>

Table of Contents
SUBMISSION DETAILS..........................................................................................................................1
1. GLOSSARY OF TERMS................................................................................................................3
INTRODUCTION...................................................................................................................................4
1.1 SYSTEM DESIGN SECTIONS........................................................................................................4
1.2 TSG OFFERS ASSISTANCE TO PUBLIC SECTOR ORGANISATION.................................................5
2. SYSTEM DESIGN CHANGE LOG..............................................................................................6
3. GATE 1: BASIC SOLUTION PROFILE......................................................................................7

3.1 HIGH LEVEL BUSINESS SCOPE OF SOLUTION.............................................................................7
3.2 BASIC SYSTEM CHECKLIST........................................................................................................8
3.3 FUNCTIONAL SYSTEM DESCRIPTION........................................................................................12
3.4 CONCEPTUAL SYSTEM DESIGN DESCRIPTION..........................................................................16
4. GATE 2: PRELIMINARY SYSTEM DESIGN..........................................................................17
4.1 PRELIMINARY SYSTEM CHECKLIST..........................................................................................17
4.2 DEVELOPMENT QUALITY DESCRIPTION...................................................................................19
4.3 PRELIMINARY SYSTEM DESIGN DESCRIPTION..........................................................................20
4.4 SYSTEM ARCHITECTURE QUALITY DESCRIPTION.....................................................................21
5. 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 NETWORK DOMAIN:.................................................................................................................30
6.2 APPLICATION DOMAIN:............................................................................................................30
6.3 DATA DOMAIN:.........................................................................................................................30
6.4 SYSTEMS INTEGRATION DOMAIN:............................................................................................30
6.5 GROUPWARE DOMAIN:.............................................................................................................30
6.6 PLATFORM DOMAIN:................................................................................................................30
6.7 ENTERPRISE MANAGEMENT DOMAIN:.....................................................................................30
6.8 SECURITY DOMAIN:..................................................................................................................30
7. Appendix A – Service Contract/ Adapter Definition.......................................................................31
Solution Architecture Document Template Version: 1.0 Page 2 of 36

Technology Strategy and Governance
Malta Information Technology Agency
Telephone: (+356) 21234710 Facsimile: (+356) 21234701
Web Site: www.mita.gov.mt
1. Glossary of terms
This section includes the descriptions of all abbreviations, terms or terminologies used throughout the
document.
Project Type: A system being submitted for Solution Architecture Assessment for
New System the first time which has never been approved.
Project Type: An Upgrade of the System refers to an addition/change of any of the
Upgrade System 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
(In the context of Backups) 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.
Warm Site A warm site is, quite logically, a compromise between hot and cold.
(In the context of Backups) 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.
Hot Site A hot site is a duplicate of the original site of the organization, with
(In the context of Backups) 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.

Private Runtime A Private Runtime Environment (PRE) is an environment which
Environment (PRE) enables Contractors to locate their Solution in a segregated
Principles 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-REP-
PrivateRuntimeEnvironment_Public-v2.0.pdf); The document
outlines the responsibilities of MITA and the Contractor in relation to
the PRE.
PSO Public Sector Organisation
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 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

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 Version Date

(For instructional purposes examples have been
provided)
Example: New System: 1.0 13/02/2010
MyPassport- This system includes the introduction of
biometric passports.
Example: Upgrade: 2.0 30/03/2010
MyPassport- Added the use of a new web service.

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  Which local law / directive mandate the creation of a solution?
context of Government’s
business)
 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 Capital Expenditure (CAPEX) _______(Euros)

Allocated (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)

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 ICT Policies and Directive can be found at http://ictpolicies.gov.mt.
Policies/Directives
Highlight any deviations (providing detailed description) to the Policies/
Such as: Directives found in the above URL.
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).
Estimated Total Number of Concurrent Total: _________

Customers 
By Audience:
Note: For systems were functionality will be delivered over time specify amounts by
implementation phase.
Estimated Annual Customer Growth Rate Percentage: _________
By Audience:
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
__ 24 X 7
__ Government/Business Partner(s)
__ 24 X 7

Production Availability Expectations on a Kindly highlight any peaks and troughs of the service being rendered?
monthly basis 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 => Downtime/month (i.e. unplanned)

__ 99 (2 Nines) => 7h 30m
__ 99.5 => 4h 45m
__ 99.9 (3 Nines) => 1h 45m
__ 99.99 (4 Nines) => 5m
__ 99.999 (5 Nines) => 30s
__ Other (specify):
Scheduled Downtime:
__ Minutes (specify amount):________
__ Hours (specify amount):__________
Service Restoration:
MTBF: (Mean Time Between Failure)

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):________
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-and-
Considerations-v1.0.pdf)
__ Traditional

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_IMS-
GDL-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-GDL-
ServiceHostingCatalogue-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-GDL-
ServiceHostingCatalogue-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

System Usage of Government Shared __ myBills

Services 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 3 rd 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.
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)
Accounts Accounts Fixed Internal

Employees Purchasing
Payable Receivable Assets Agency
Interfaces
(e.g Payroll,
And HR)
General Ledger
External
Business Direct Bank Agency
Deposits Reconciliation Interfaces
(Specify)
Billing Shipping
Citizens Reporting
Note: Narrative describing the functional design of the application must be provided
immediately following the diagram(s).

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.
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.

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.
Financial Management Application – Conceptual Design
Hardened Internal
Internet DMZ Internal Network
Network
Firewall 2
Firewall 1
Firewall 3
Web Application Database
Citizen Employee Server Server
Server
Firewall 3
Single Credit Card

Messaging
(or Reduced) EDI Processing
Middleware
Sign-on Service
Service
External External
Business Agency
Partner Application
Note: Narrative describing the conceptual design of the application must be provided

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
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 Service Interface:
(Within the Solution Domain) __ Web Services (HTTP, XML, SOAP, WSDL, UDDI)
__ Public Facing
__ Internal Facing
__ Messaging / Message Queuing
Platform Specific:
__ .NET Remoting
__ EJB/RMI – IIOP
__ Other (specify):
Preliminary System Checklist Responses – Select all that apply
System Integration Technologies __ XML __ Web Services __ Messaging __ EDI __ CORBA
(Both for service provisioning and service __ IIOP __ Adaptors __ Secure FTP
consumption) __ 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/

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.

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.
Line of Business Application – Logical Design
Transaction Zone 3
Zone 0/1 Zone 2
Zone (Hardened Internal
Internet (Internal Network)
(Hardened DMZ) Network)
Transaction Zone Firewall
VPN VPN VPN VPN

Zone 2 Firewall
Citizen
Zone 3 Firewall
(5000
Load Balancer
Transactions Employee DB
Per day Web Desktop Appl. Server
Server (N=300) Server
SSL (Mirror)
(Cluster)
Remote Zone 3 Firewall

Access VPN VPN
Employees Identity Common Payment
Service
(N=50) Access EDI Service
Broker
Management (CC and ACH)
System Dedicated Circuit VPN
WAN
Field External External Credit
Employees Business Agency Card
(N=100) Partner Application Authorization
Note: Narrative describing the preliminary design of the application must be provided

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.
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.
Availability
The ability of the system to function without service interruption or depletion despite abnormal or malicious events.
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
requirements.
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.
Serviceability
The ease and extent of changes that can be affected without interrupting the application and the environment, consequently
affecting availability.
Recoverability
The ability towards a fast, easy, and reliable recovery of business data from virtually any disruption or event.

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
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

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:
Web Server - High Availability Load Balanced: __ Yes __ No
__ Other (specify):
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: __________
For PRE hosting; additional information is required (refer to PRE

Documentation -
PrivateRuntimeEnvironment_Public-v2.0.pdf)

Presentation – Server Side Languages __ ASP.NET __ VB.NET __C#
__ JSP __ Servlets __ Java
__ 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:

Documentation -
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)
__ C++
__ Other (specify):
Database Server Operating System __ Windows __ Linux __ Unix __ Other (specify):
Specify Version:
Database Server Software __ Microsoft __ IBM __ Oracle __ Other (specify):
Specify Version:

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:

Documentation -
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.

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: Narrative describing the detail design of the application must be provided
5.2.2 Computing Resources Required
5.2.2.1 Type 1A Hosting – Hardware Provided By Solution Provider

Data Centre Facilities
Query Response
Number of Physical Servers
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
Number of Guests
Query for each Guest Response
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)

5.2.3 Network Access Requirement (Type 1A, Type 1B and Type 2 Hosting)
Access Access
Access Required for each required required TCP/UDP
Guest from to 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.

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:
6.3 Data Domain:
6.4 Systems Integration Domain:
6.5 Groupware Domain:
6.6 Platform Domain:
6.7 Enterprise Management Domain:
6.8 Security Domain:

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

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.

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: Technical Document

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Solution Architecture: Technical Document

Uploaded by

Copyright:

Available Formats

< Project Name > Solution Architecture

<Company Name> <Company Logo>

Project Name: <Project name>

Submission Contact Name: <Contact name> Ministry / Department / <Entity name>

Submission Contact Title: <CTO / CIO / Officer / IMU / Supplier>

Submission Contact Details: <email> / <telephone> / <mobile>

Project Completion Date: <Date>

Supplier: <Supplier name> Supplier Contact <Supplier contact

Supplier Contact Details: <email> / <telephone> / <mobile>

Client Name: <Client name> Ministry / Department / <Entity name>

Client Contact Details: <email> / <telephone> / <mobile>

3. GATE 1: BASIC SOLUTION PROFILE......................................................................................7

Solution Architecture Document Template Version: 1.0 Page 2 of 36

Solution Architecture Document Template Version: 1.0 Page 3 of 36

1.1 System Design Sections

Acronym Description Scenario

Note: a valid reason for not providing the information must

Solution Architecture Document Template Version: 1.0 Page 4 of 36

 Basic Profile Section: This section of the document is required to be submitted,

Solution Assessment Gates

1.2 TSG Offers Assistance to Public Sector Organisation

Solution Architecture Document Template Version: 1.0 Page 5 of 36

Change Log Summary – Description Version Date

Solution Architecture Document Template Version: 1.0 Page 6 of 36

3.1 High Level Business Scope of Solution

Business Context Checklist

EU Initiative / Obligations __ No __ Yes

 By when does the solution need to be live / available for use?

Monetary Value / Budget Capital Expenditure (CAPEX) _______(Euros)

Operational Expenditure (OPEX) _______(Euros)

Solution Architecture Document Template Version: 1.0 Page 7 of 36

Solution Scope ___ International

Solution Architecture Document Template Version: 1.0 Page 8 of 36

Conceptual System Checklist Responses - Select all that apply

Delivery of Functionality __ Functionality delivered over time

__ Government to Business (G2B)

__ Government to Government (G2G)

__ Government to Other Government (G2OG)

Estimated Total Number of Concurrent Total: _________

Note: For modular delivery specify amounts by implementation phase.

Solution Architecture Document Template Version: 1.0 Page 10 of 36

What are the repercussions if the system fails?

Uptime => Downtime/month (i.e. unplanned)

MTBF: (Mean Time Between Failure)

Note: Please indicate how the SLA shall be monitored

Solution Architecture Document Template Version: 1.0 Page 11 of 36

__ Dedicated Environment at the Government Data Centers managed by

__ Dedicated Environment at the Government Data Centers managed by

__ Hosting managed & supported at 3rd parties

Solution Architecture Document Template Version: 1.0 Page 12 of 36

System Usage of Government Shared __ myBills

Kindly highlight any usage peaks of the service/s being consumed

NOTE: For Gate 2 approval the respective service contract

NOTE: For Gate 2 approval the respective service contract

3.3 Functional System Description

Financial Management Application

Accounts Accounts Fixed Internal

Solution Architecture Document Template Version: 1.0 Page 14 of 36

Transaction Use Case

Withdrawal Transaction Use Case

Solution Architecture Document Template Version: 1.0 Page 16 of 36

Financial Management Application – Conceptual Design

Single Credit Card

EU Initiative / Obligations No Yes

Presentation - Client Side Languages HTML DHTML XML XHTML

Processor Architecture: 64 Bit 32 Bit

Virtualization Technologies _ Server Virtualization: Vendor:________

Data Access – Connectivity Methods ADO.NET ODBC __ OLE/DB