<Project Name> Solution Architecture Preliminary System Design

Transcription

1 <Project Name> Solution Architecture Preliminary System Design Gate 2 Date: <dd/mmm/yyyy> Version: <nn.nn> <Company Name> <Company Logo>

2 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 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 Solution Architecture Document Template Version: 1.1 Page 2 of 8

3 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 ) Software License Framework Web Based Architectural Approach Processing Type Development Platform Architectural Framework(s) Architectural Pattern(s) 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 NOTE: Specify License Framework. Such as GPLv3, EUPL, LGPL, BSD, etc. Yes No Virtualizable: Yes No NOTE: For non web based solutions indicate if the desktop application can be abstracted via virtualization. SOA 3/N Tier Other (specify): OLTP OLAP Other (specify): J2EE.NET Other (specify): Version STRUTS JATO JSF Other (specify): MVC Factory Controller Data Access Object Other (specify): Solution Architecture Document Template Version: 1.1 Page 3 of 8

4 Preliminary Solution Checklist Application Communication Technologies (Within the Solution Domain) Responses Select all that apply Service Interface: Web Services (HTTP, XML, SOAP, WSDL, UDDI) Public Facing Internal Facing Messaging / Message Queuing Solution Integration Technologies (Both for service provisioning and service consumption) Platform Specific:.NET Remoting EJB/RMI IIOP Other (specify): XML Web Services Messaging EDI CORBA IIOP Adaptors Secure FTP Proprietary API via Other (specify): Security Technologies 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. 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 Solution Architecture Document Template Version: 1.1 Page 4 of 8

5 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. Solution Architecture Document Template Version: 1.1 Page 5 of 8

6 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 and 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 Zone 0/1 Internet Citizen (5000 Transactions Per day SSL Transaction Zone Firewall Load Balancer Transaction Zone (Hardened DMZ) Web Server Zone 2 Firewall Zone 2 (Internal Network) Employee Desktop (N=300) Zone 3 Firewall Zone 3 (Hardened Internal Network) Appl. Server (Cluster) DB Server (Mirror) Remote Access Employees (N=50) Field Employees (N=100) WAN Identity Access Management System Zone 3 Firewall EDI Dedicated Circuit External Business Partner Service Broker External Agency Application Common Payment Service (CC and ACH) Credit Card Authorization SAMPLE Solution Architecture Document Template Version: 1.1 Page 6 of 8

7 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 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. 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 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. Availability The ability of the solution 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 Solution Architecture Document Template Version: 1.1 Page 7 of 8

8 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. Solution Architecture Document Template Version: 1.1 Page 8 of 8