Solution Architecture Preliminary Solution Design

Solution Architecture – Preliminary Solution Design ■Gate 2

■Gate 2 Solution Architecture Submission for

1 Preliminary Solution Design Change Log

Any moderate or significant changes to the solution 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 [email protected] 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) <04/10/2011> Quality Description section> (Note: this entry is for (Note: this entry is for (Note: this entry is for instructional purposes) instructional purposes) instructional purposes) ■Gate 2 Solution Architecture Submission for

2 Preliminary Solution Design

The Preliminary Solution 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.

2.1 Preliminary Solution 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 Solution 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 Licenses  Specify the license frameworks that have been agreed upon (including any IPR arrangements): (NOTE: Specify License Framework. Such as GPLv3, EUPL, LGPL, BSD, MITA IPR, etc)  Specify how other dependent software required by the solution (such as Operating Systems / Application Servers / Database Servers including any Client Access Licenses (CALs) ) shall be procured: Web Based Is the solution web based?   If not web based, is it virtualizable? 

(NOTE: For non web based solutions indicate if the desktop application can be abstracted via virtualization) Architectural Approach  SOA:   3/N Tier:   Other: Processing Type  OLTP:   OLAP:   Other: Development Platform  J2EE:  Version:  .NET:  Version:  Other: Version:

Solution Architecture Document Template Version: 3.0 Page 1 Malta Information Technology Agency - Technology and Systems Governance Telephone: (+356) 21234710 Fax: (+356) 21234701 Website: www.mita.gov.mt ■Gate 2 Solution Architecture Submission for

Architectural Framework(s)  STRUTS:   JATO:   JSF:   Other: Architectural Pattern(s)  MVC:   Factory:   Controller:   Data Access Object:   Other: Application Communication Service Interface: Technologies  Web Services (HTTP, XML, SOAP, WSDL, UDDI):  (Within the Solution Domain) o Public Facing:  o Internal Facing:   Messaging /Message Queuing: 

Platform Specific:  .NET Remoting:   EJB/RMI – IIOP: 

Other: Insert other platform specific communication technologies> Solution Integration  XML:  Technologies  Web Services:  (Both for service provisioning and service consumption)  Messaging:   EDI:   CORBA:   IIOP:   Adaptors:   Secure FTP:   Proprietary API:  Via:  Other:

(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 In case of websites, illustrate how the solution will be secured against:  SQL Injection:  Cross Site Scripting:  Other: (Ensure that the solution is inline with OWASP top 10 https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project )

Secure Authentication: (How is the user authentication process secured? What authentication mechanism and security level is being proposed? What technologies are being proposed? Please highlight the authentication mechanism and level used for each respective user type and role)

Secure transport: (How is data secured in transit? What technologies/mechanisms are being proposed?)

Secure Storage: (How is data secured when persisted? What technologies/mechanisms are being proposed?)

(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 Capacity Growth State the envisaged capacity growth for the solution in terms of the following:

 Network Bandwidth (Intra/Internet):  Storage (DBMS/File System/Entire VM Image):  (Scale horizontal or scale out is the process of adding more nodes to a system. For example: a single web server system is scaled out to a three web server system. Scale vertical or scale up is the process of adding more resources to a node. For example: adding memory to a single server)

(Note: this section is associated with the Estimated Total Number of Consumers, Estimated Total Number of Concurrent Consumers and Estimated Annual Customer Growth Rate sections in Gate 1) Business Domain Specify whether the application will make use of Protocols/Standards protocols/standards which are mandated by the business domain through either best practices, legal mandate or EU law/directive/outcome: (e.g.HL7 for the health Industry)

Performance Requirements Please specify 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 solution handle individual requests, what a real user would experience)  Throughput: (How many requests the solution can handle)  Concurrency: (How many users or threads work simultaneously)

(Note: Fill as deemed necessary) Application Backup Full Backup:  Requirements  Daily:   Weekly: 

Incremental Backup:   Hourly:   Daily:   Weekly:  Production Availability Scheduled Downtime: Expectations on a monthly basis  Hours:  Minutes:

Service Restoration:  Hours:  Minutes: Electronic Identity (eID) Citizen authentication level required: (This section should only be populated if  Username and Password:  the solution will make use of eID)  Username, Password and Certificate: 

Select all the relevant options:  Business Authentication:   Support Service Delegation:   Support Agent Functionality: 

(eID developer’s toolkit is accessible from the following address: https://www.mita.gov.mt/page.aspx?pageid=258)

Government Public State if the solution requires to authenticate public service Administration Federated employees:  Authentication (GPA IDP) (This section should only be populated if (Please note that the GPA IDP returns the following attributes upon successful the solution will require to authenticate authentication (outgoing claims): Public Service Employees)  Name, (e.g. Joe)  Surname, (e.g. Borg)  Email address (e.g. [email protected]) and  User account name. (e.g. [email protected]))

(The user account name should be used as the user unique identifier)

(The Government Public Administration Federated Authentication guidelines is accessible via the following address: https://www.mita.gov.mt/MediaCenter/PDFs/1_TSG-GDL-Government %20Public%20Administration%20Federated%20Authentication%20Guidelines- v1.0.pdf) myBills The solution will: (This section should only be populated if  Make use of myBills Hosted Payment Page:  the solution will make use of myBills)  And shall fully integrate with myBills: 

(Have a look at the Electronic Payment Policy accessible via the following address: https://www.mita.gov.mt/MediaCenter/PDFs/1_GMICT_P_0105_Electronic_Pay ments_v1.0.pdf)

(myBills developer’s toolkit is accessible from the following address: https://www.mita.gov.mt/page.aspx?pageid=261) Mobile Government (mGov) With regards to the use of mGov, select all the relevant options (This section should only be populated if from below: the solution will make use of mGov)  Sending messages:   Sending and receiving messages:   Sending bulk mobile messages:   Sending bulk electronic messages: 

(Have a look at the Mobile Messaging Service Policy accessible via the following address: https://www.mita.gov.mt/MediaCenter/PDFs/1_GMICT_P_0107_Mobile_Messa ging_Service_v1.0.pdf)

(mGov developer’s toolkit is accessible from the following address: https://www.mita.gov.mt/page.aspx?pageid=262)

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

2.3 Preliminary Solution 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/edev 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.

Line of Business Application – Logical Design

Transaction Zone 3 Zone 0/1 Zone 2 Zone (Hardened Internal Internet (Internal Network) l

l (Hardened DMZ) Network) a w l e

r VPN VPN VPN l i l a a F w

Citizen w e e r e i n r

(5000 i o F r

Transactions n

Employee n e

o DB e a i n l t n

Web o a Per day c Desktop Appl. o Z

a Server B Z

s Server d n (N=300) Server

a (Mirror) r o T L (Cluster)

Remote Zone 3 Firewall Access VPN VPN Identity Common Payment Employees Service Access EDI Service (N=50) Broker Management (CC and ACH) System Dedicated Circuit VPN WAN Field External External Credit Employees Business Agency Card (N=100) Partner Application Authorization SAMPLE

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

Note: this section should provide information for both the hosting environment and solution’s areas.

Performance/Throughput  Response times: (How fast the solution handles individual requests in terms of user experience)  Throughput: (How many requests the solution can handle)  Concurrency: (How many users or threads work simultaneously)

(Specify 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 solution 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 solution was used in accordance with stated security policies)  Assurance: (The ability to test and prove that the solution 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 solution, and add or change the persons or entities related to the solution)

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

(Specify the mechanism/s that the solution uses to achieve/support the above mentioned factors) Reliability

(The ability for a solution 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)

(Specify the mechanism/s that the solution uses to achieve/support the above mentioned factors) Availability

(The ability of the solution to function without service interruption or depletion despite abnormal or malicious events)

(Specify 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 requirements)

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

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

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

(Specify the mechanism/s that the solution uses to achieve/support the above mentioned factors)

Appendix A – Service Contract/Adapter Definition

Section 1 – Functional

 Consumption Information

(Example: The service 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.

Access control is configured through Firewalls at the Segregated Environment Edge.

Each message is scanned against a list of viruses and malicious content)

 Interfaces provided

 Standards

Standard Information

 Location of Documentation

Section 2 – Other Terms of Usage

 Transactional

 Service Level Terms and Conditions

(Example: 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)

 Quality of Service

(Example: 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)

 Auditing Information

 Defined processes

(Example: Requests for consumption of this adapter are controlled by MITA. A change request is required to open port 25 from the Segregated Hosting Environment to the service as defined under interfaces.

Requests for access to the adapter are identified through the solution architecture to be presented according to the Solution Architecture Templates available at http://mita.gov.mt. Project Manager is responsible to trigger change management process)

Section 3 – Responsibilities

This section should provide information about the roles and persons responsible for the provision of the service through this adapter.

Responsible Role Accountable Role Consultative Role Informative Role

Solution Architecture Document Template Version: 3.0 Page 11 Malta Information Technology Agency - Technology and Systems Governance Telephone: (+356) 21234710 Fax: (+356) 21234701 Website: www.mita.gov.mt