· web viewsolution architecture – detailed solution design gate 3. date: version: detailed...

<Project Name>Solution Architecture – Detailed Solution Design

■Gate 3

Date: <dd/mm/yyyy>Version: <nn.nn>

<Company Name> <Company Logo>

■Gate 3 Solution Architecture Submission for <Project Name>

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

[A]Change Log Summary – Description(For instructional purposes examples have been provided)

Version Date

<Included further information within the Technical Architecture Domains>(Note: this entry is for instructional purposes)

<2.0>(Note: this entry is for instructional purposes)

<04/10/2011>(Note: this entry is for instructional purposes)

mailto:[email protected]


2 Detail Solution Design

The Detail Solution 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 a solution, it does reflect some of the more common choices as well as important items that should be considered during the design phase.

2.1 Detail Solution Design 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.

Detail Solution Checklist Responses – Select all that apply

[A] 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: Type (PDA, Smartphone etc): <Insert desktop type> OS (Linux, Android, Palm etc): <Insert OS> OS Version: <Insert OS version>

(Please fill in the above (Non Standard Desktop) information, if platform differs from the standard Government Hardware and Desktop Configuration)

[B] Client Application Footprint by Platform

Specify size of application footprint in KB or MB: <Insert application footprint for the client>

(This information will serve as an indication in case the solution needs to be virtualised/streamed)

[C] Client Connection Speed

Specify bandwidth in kbps or mbps: Minimum: <Insert minimum bandwidth> Recommended: <Insert the recommended bandwidth>

(Considerations depend on the client platform type including whether the connection is wired or wireless)

[D] Client Richness Browser Based: Rich Internet (AJAX, Flash etc): Rich Client:

Solution Architecture Document Template Version: 3.0 Page 1Malta Information Technology Agency - Technology and Systems Governance

Telephone: (+356) 21234710 Fax: (+356) 21234701Website: www.mita.gov.mt

http://www.mita.gov.mt/



[E] Browser Support The solution must be compatible and support the Major Internet Web Browsers.

Specify the compatible web browsers and their respective versions: Mozilla Firefox: Version: <Insert Version> Internet Explorer: Version: <Insert Version> Google Chrome: Version: <Insert Version> Opera: Version: <Insert Version> Safari: Version: <Insert Version> Other: <Insert other web browser> Version: <Insert Version>

[F] Application State Cookies: o Non-Persistent: o Persistent:

Session Ids: State Stored in Hidden Fields: Other: <Specify other application states>

[G] Web Server Location Public Facing: Internal Facing:

[H] Virtualization Technologies

Server Virtualization: Vendor: <Insert vendor> Storage Virtualization: Vendor: <Insert vendor> Application Virtualization: Vendor: <Insert vendor> VDI: Vendor: <Insert vendor> Other: <Specify other> Vendor: <Insert vendor>

[I] Data Access – Connectivity Methods

ADO.NET: ODBC: OLE/DB: JDBC: JDO: DB2 Connect: Other: <Specify other>

[J] SQL Languages T/SQL: PL/SQL: Other: <Insert other SQL languages>

(Use of SQL ANSI 92/99 (and appropriate successors) compliant constructs)

[K] Stored Procedures Utilization

Use of stored procedures: 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)






[L] Licenses Specify how are the licenses for the operating system and software being procured: <Insert source of procurement>

[M] Operating System

Web Server Application Server Database Server

Windows

<Insert Version> <Insert Version> <Insert Version>

Linux


Unix


Other<Insert OS Name> <Insert OS Name> <Insert OS Name>


[N] Software


Apache

<Insert Edition & Version>

Microsoft

<Insert Edition & Version> <Insert Edition & Version> <Insert Edition & Version>

Sun

<Insert Edition & Version> <Insert Edition & Version>

Oracle


BEA

<Insert Edition & Version>

IBM

<Insert Edition & Version> <Insert Edition & Version>

Other<Insert Software Name> <Insert Software Name> <Insert Software Name>


[O] High Availability






Clustered

Load Balanced

Raid Supported

SAN Supported

Mirroring Supported

Clustering Supported

Grid/On Demand Supported

Other <Insert Other> <Insert Other> <Insert Other>

[P] Specifications – Roll Out Configuration


Number of Servers

<Insert Number of Servers>



CPUs Per Server

<Insert number of CPUs per Server>



CPU Type <Insert CPU Type> <Insert CPU Type> <Insert CPU Type>

CPU Speed <Insert CPU Speed> <Insert CPU Speed> <Insert CPU Speed>

Amount of RAM <Insert amount of RAM> <Insert amount of RAM> <Insert amount of RAM>

[Q] Specifications – Maximum Configuration


Number of Servers








CPUs Per Server




CPU Type <Insert CPU Type> <Insert CPU Type> <Insert CPU Type>

CPU Speed <Insert CPU Speed> <Insert CPU Speed> <Insert CPU Speed>

Amount of RAM <Insert amount of RAM> <Insert amount of RAM> <Insert amount of RAM>

[R] Processor Architecture


32 bit

64 bit

[S] Presentation and Business Rule Languages

Presentation – Client Side Languages

Presentation – Server Side Languages

Business Rule – Application Languages

HTML

DHTML

XML

XHTML

ASP.NET

VB.NET

C#

Flash

Java Applets

Java

<JVM: Specify Details> <JVM: Specify Details> <JVM: Specify Details>

Java Script

VBScript

C++

Servlets

Server Side Includes (SSI)





Other <Specify other languages>

<Specify other languages>

<Specify other languages>

2.2 Detail Solution 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 solution. 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/edev 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.

2.2.1 Detail Solution Design – Infrastructure Architecture




https://www.mita.gov.mt/edev

http://ictpolicies.gov.mt/


2.2.2 Required Computing Resources

2.2.2.1 Type 1A Hosting – Hardware Provided By Solution Provider – Data Centre Facilities[A] Query Response

Number of Physical Servers <Insert number>

Rack Space required (in rack Height Units) <Insert rack space required>

Air Flow Direction (e.g. Front-bottom-up, etc) <Insert air flow direction>

Total Heat Dissipation (Btu/Hr) <Insert total heat dissipation>

Total Power Consumption (kVA) <Insert total power consumption>

Operating Temperature (degrees Celsius) <Insert operating temperature>

2.2.2.2 Type 1B Hosting – Computing Resources Provided by MITA – Virtualised Environment Requirement

[A] Query Response

Number of Guests <Insert number of guests>

[B] Query for each Guest Response

CPU (GHZ) <Insert CPU speed>

RAM (GB) <Insert RAM>

Hard disk space (GB) <Insert hard disk space>

Number of Network interfaces <Insert number of network interfaces>

Bandwidth needed for each interface (KBps) <Insert bandwidth required>

Frequency of backups(daily/weekly/monthly) <Insert frequency of the backups>

Can server be shut down during the backup process? (Yes/No)

<Insert whether server can be shut down during backup>

Operating Solution (Windows Linux x64/x86) <Insert operating solution>

Database Management Server (e.g. SQL; Oracle( if any)

<Insert database management server>

2.2.3 Network Access Requirement (Type 1A, Type 1B and Type 2 Hosting)

[A] Access Required for each Guest

Accessrequired from

Access required to TCP/UDP port

Access required

both ways

Anti Virus (updates of AV) <Insert Access> <Insert Access> <TCP/UDP Port>

Netbios <Insert Access> <Insert Access> <TCP/UDP Port>

OS Updates <Insert Access> <Insert Access> <TCP/UDP Port>





DNS <Insert Access> <Insert Access> <TCP/UDP Port>

Remote support (RDP/SSH) <Insert Access> <Insert Access> <TCP/UDP Port>

Internet Access <Insert Access> <Insert Access> <TCP/UDP Port>

HTTP <Insert Access> <Insert Access> <TCP/UDP Port>

HTTPS <Insert Access> <Insert Access> <TCP/UDP Port>

SMTP <Insert Access> <Insert Access> <TCP/UDP Port>

POP3 <Insert Access> <Insert Access> <TCP/UDP Port>

IMAP <Insert Access> <Insert Access> <TCP/UDP Port>

IMAPS <Insert Access> <Insert Access> <TCP/UDP Port>

2.2.4 Detail Solution Design – Application ArchitectureProvide a detailed solution design reflecting the Presentation Layer, Business Layer and Data Access Layer.

Sample Diagram

<If the solution will make use of mGov the following information must be provided: (a) flow diagram illustrating the registration/de-registration processes, (b) how acknowledgements will be processed>

<If the solution will make use of CDR, kindly indicate the web methods that will be used>

<Provide the minimum account privileges required for the solution to successfully operate>





2.3 Technical Architecture Domains

Please provide any additional significant architectural information (that has not been provided within the previous sections) for this solution. 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.

2.3.1 Network Domain<Insert architectural information on the network domain>

2.3.2 Application Domain<Insert architectural information on the application domain>

2.3.3 Data Domain<Insert architectural information on the data domain>

2.3.4 Solutions Integration Domain<Insert architectural information on the solution integration domain>

2.3.5 Groupware Domain<Insert architectural information on the groupware domain>

2.3.6 Platform Domain<Insert architectural information on the platform domain>

2.3.7 Enterprise Management Domain<Insert architectural information on the enterprise management domain>

2.3.8 Security Domain<Insert architectural information on the security domain>




· web viewsolution architecture – detailed solution design gate 3. date: version: detailed...

Documents