Solution Architecture Template Preliminary Solution Design

Insert project name

Solution Architecture Template – Preliminary Solution Design

■Gate 2

Date: Insert publish date of this document

Version: Insert current version number of this document

Security Classification: Select classification for this document from confidential, restricted, unclassified or public

Insert company name / Insert company logo
■Gate 2 / Solution Architecture Submission for Insert project name

01. 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 for clarification.

3.  Maintain a summary of changes in the table below.

1.1 Change Log Summary – Description / Version / Date
Insert description of the changes / Insert / Insert

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

02.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 – Select all that apply /
2.1.1 / Development Approach:
Yes / No
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.
2.1.2 / Software Licenses:
·  Specify the license frameworks that have been agreed upon (including any IPR arrangements):
Insert
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:
Insert
2.1.3 / Web Based:
·  Is the solution web based?
Yes/No
o  If not web based, is it virtualizable?
Yes/No
NOTE: For non web based solutions indicate if the desktop application can be abstracted via virtualization.
2.1.4 / Architectural Approach:
Yes / No
SOA
3/N Tier
Specify Other (if any)
2.1.5 / Processing Type:
Yes / No
OLTP
OLAP
Specify Other (if any)
2.1.6 / Development Platform:
Yes / No / Specify version
J2EE
.NET
Specify Other (if any)
2.1.7 / Architectural Framework(s):
Yes / No
STRUTS
JATO
JSF
Specify Other (if any)
2.1.8 / Architectural Pattern(s):
Yes / No
MVC
Factory
Controller
Data Access Object
Specify Other (if any)
2.1.9 / Application Details:
·  Application name:
Insert
·  Application uses an existing database?
Yes/No
If the answer to the previous question is Yes, please proceed to the next set of questions:
·  Was the database documented in a previous solution architecture assessment?
Yes/No
·  If the answer to the previous question is Yes, enter the following details:
o  Existing Database Name:
Insert
o  Project Name:
Insert
·  If the answer is No, enter the following details:
o  Database Name:
Insert
o  Technology platform or product used to implement Database (include version):
Insert
o  Attach Database Schema:
Attach
Minimum items required for the database schema are:
·  Database Name:
·  Table Name:
·  Attribute Name,
·  Attribute Type,
·  Attribute Length.
Note: The schema is preferably scripted in an XML format as defined in the XSD schema provided in Appendix B.
2.1.10 / New Database Details:
Ignore this section if the application is not using a new database.
If application uses multiple new databases, add one entry per database.
·  Database Name:
Insert
·  Technology platform or product used to implement Database (include version):
Insert
·  Attach Database Schema:
Attach
Minimum items required for the database schema are:
·  Database Name:
·  Table Name:
·  Attribute Name,
·  Attribute Type,
·  Attribute Length.
Note: The schema is preferably scripted in an XML format as defined in the XSD schema provided in Appendix B.
2.1.11 / Application Communication Technologies:
Within the Solution Domain.
Service Interface:
·  Web Services (HTTP, XML, SOAP, WSDL, UDDI):
Yes/No
o  Public Facing:
Yes/No
o  Internal Facing:
Yes/No
·  Messaging /Message Queuing:
Yes/No
Platform Specific:
·  .NET Remoting:
Yes/No
·  EJB/RMI – IIOP:
Yes/No
Other:
·  Insert
2.1.12 / Solution Integration Technologies:
Both for service provisioning and service consumption.
Yes / No
XML
Web Services
Messaging
EDI
CORBA
IIOP
Adaptors
Secure FTP
Proprietary API: Specify Other (if any)
Specify Other (if any)
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.
2.1.13 / Security Technologies:
·  In case of websites, illustrate how the solution will be secured against:
o  SQL Injection:
Insert
o  Cross Site Scripting:
Insert
o  Other:
Insert other
Ensure that the solution is in-line with OWASP top 10 https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project.
·  Secure Authentication:
Insert
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:
Insert
How is data secured in transit? What technologies/mechanisms are being proposed?
·  Secure Storage:
Insert
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/.
2.1.14 / Solution Capacity Growth:
·  State the envisaged capacity growth for the solution in terms of the following:
o  Network Bandwidth (Intra/Internet):
Insert
o  Storage (DBMS/File System/Entire VM Image):
Insert
o  How can the solution scale horizontally and vertically?
Insert
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.
2.1.15 / Business Domain Protocols/Standards:
·  Specify whether the application will make use of 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):
Insert
2.1.16 / 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.
o  Response times:
Insert
How fast the solution handles individual requests, what a real user would experience.
o  Throughput:
Insert
How many requests the solution can handle.
o  Concurrency:
Insert
How many users or threads work simultaneously?
2.1.17 / Application Backup Requirements:
·  Full Backup:
Yes/No
o  Daily:
Yes/No
o  Weekly:
Yes/No
·  Incremental Backup:
Yes/No
o  Hourly:
Yes/No
o  Daily:
Yes/No
o  Weekly:
Yes/No
2.1.18 / Production Availability Expectations on a monthly basis:
·  Scheduled Downtime:
o  Hours:
Insert
o  Minutes:
Insert
·  Service Restoration:
o  Hours:
Insert
o  Minutes:
Insert
2.1.19 / Electronic Identity (eID):
·  Yes/No/NA
This section should only be populated if the solution will make use of eID.
Citizen authentication level required:
·  Username and Password:
Yes/No
·  Username, Password and Certificate:
Yes/No
Select all the relevant options:
·  Business Authentication:
Yes/No
·  Support Service Delegation:
Yes/No
·  Support Agent Functionality:
Yes/No
eID developer’s toolkit is accessible from the following address: https://www.mita.gov.mt/page.aspx?pageid=258.
It is important to highlight that due to the exclusivity of e-ID authentication as highlighted in the OPM circular No. 15/2007, whenever a public facing government website (gov.mt) requires an additional authentication mechanism, the following process needs to be carried out:
1.  Client/CIO needs to sends a request/business case to the parliament secretary of the Minister of Investment, Industry and Information Technology () copying the IDMO () explaining the reason why an additional authentication mechanism is required,
2.  IDMO shall submit advice to PS, MITC and issue reply accordingly,
3.  IDMO will keep MITA’s ICT compliance team () copied on such requests and outcomes.
2.1.20 / Government Public Administration Federated Authentication (GPA IDP):
·  Yes/No/NA
Please note that the GPA IDP returns the following attributes upon successful authentication (outgoing claims):
·  Name, (e.g. Joe),
·  Surname, (e.g. Borg),
·  Email address (e.g. ) and
·  User account name. (e.g. ).
In order to provide a refined authorisation scheme, the following claims can be made available upon request:
·  Account Name (e.g. borgj999),
·  ID/Passport (e.g. 8856400M),
·  Title (e.g. Mr.),
·  Middle Name (e.g. Edward),
·  Phone (e.g. 21777777),
·  Organisation (e.g. Ministry for Infrastructure, Transport and Communications),
·  Department (e.g. Office Of The Permanent Secretary),
·  Section (e.g. European Affairs Directorate),
·  Occupation (e.g. Officer).
The user account name should be used as the user unique identifier.
The Government Public Administration Federated Authentication guidelines are accessible via the following address: https://www.mita.gov.mt/page.aspx?pageid=258.
2.1.21 / myBills:
·  Yes/No
This section should only be populated if the solution will make use of myBills.
The solution will:
·  Make use of myBills Hosted Payment Page:
Yes/No
·  And shall fully integrate with myBills:
Yes/No
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_Payments_v1.0.pdf.
myBills developer’s toolkit is accessible from the following address: https://www.mita.gov.mt/page.aspx?pageid=261.
2.1.22 / Mobile Government (mGov):
·  Yes/No/NA
This section should only be populated if the solution will make use of mGov.
With regards to the use of mGov, select all the relevant options from below:
·  Sending messages:
Yes/No
·  Sending and receiving messages:
Yes/No
·  Sending bulk mobile messages:
Yes/No
·  Sending bulk electronic messages:
Yes/No
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_Messaging_Service_v1.0.pdf.
mGov developer’s toolkit is accessible from the following address: https://www.mita.gov.mt/page.aspx?pageid=262.

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

Development Quality Description /
2.2.1 / Portability:
Insert information on the portability of the solution
The ability for a solution to be migrated/installed on a different environment other than the original one, without the need of any code changes.
2.2.2 / Maintainability:
Insert information on the maintainability of the solution
Ease of extending the solution functionality, fixing of errors etc.
2.2.3 / Extensibility:
Insert information on the extensibility of the solution
The ability for the solution to be extended with ease and with minor modifications (future proof solution).
2.2.4 / Supportability:
Insert information on the supportability of the solution
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.
2.2.5 / Re-usability:
Insert information on the re-usability of the solution
The ability to use modified or unmodified solution components (subroutines etc) in other solutions.

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

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