<Project Name>
Solution Architecture – Preliminary System Design
■
Gate 2
Date: <dd/mmm/yyyy>
Version: <nn.nn>
Gate 2 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
(For instructional purposes examples have been provided)
Version Date
2. Gate 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 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
Preliminary Solution
Checklist
Responses – Select all that apply
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 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:
Secure transport :
Secure Storage:
__ 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/
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
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.
Citizen (5000 Transactions Per day Service Broker Tr an sa ct io n Zo ne F ire w al l Employee Desktop (N=300) External Agency Zo ne 2 F ire w al l
Line of Business Application – Logical Design
Transaction Zone (Hardened DMZ) Zone 2 (Internal Network) Zone 3 (Hardened Internal Network) Zone 0/1 Internet Common Payment Service (CC and ACH) Credit Card EDI External Business Identity Access Management System Zone 3 Firewall Lo ad B al an ce r Web
Server ServerAppl.
(Cluster) DB Server (Mirror) VPN VPN Dedicated Circuit VPN VPN VPN Remote Access Employees (N=50) SSL Field Employees Zo ne 3 F ire w al l WAN VPN VPN
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.
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
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 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.
AssetProtection: 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.
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 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.
List down the mechanism/s that the solution uses to achieve/ support the above mentioned factors
Availability
capacity – computational power etc.) in a graceful manner or the ability and ease of enhancing the solution to handle new 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
