Solution Architecture Template - MITA1 … · Web viewThe Solution Architecture Template has been designed to enable Public Sector ... To facilitate this process, ... word processing

<Project Name> Solution Architecture Technical Document

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

<Company Name> <Company Logo>

Solution Architecture Submission for <Project Name>

Submission Details

Project Name: <Project name>

Submission Contact Name: <Contact name> Ministry / Department / Company

<Entity name>

Submission Contact Title: <CTO / CIO / Officer / IMU / Supplier>

Submission Contact Details: <email> / <telephone> / <mobile>

Project Completion Date: <Date>

Supplier: <Supplier name> Supplier Contact Person: <Supplier contact person>

Supplier Contact Details: <email> / <telephone> / <mobile>

Client Name: <Client name> Ministry / Department / Company

<Entity name>

Client Contact Details: <email> / <telephone> / <mobile>

Table of Contents

SUBMISSION DETAILS..........................................................................................................................1

1. GLOSSARY OF TERMS................................................................................................................3

INTRODUCTION...................................................................................................................................4

1.1 SYSTEM DESIGN SECTIONS........................................................................................................41.2 TSG OFFERS ASSISTANCE TO PUBLIC SECTOR ORGANISATION................................................5

2. SYSTEM DESIGN CHANGE LOG..............................................................................................6

3. GATE 1: BASIC SOLUTION PROFILE......................................................................................7

3.1 HIGH LEVEL BUSINESS SCOPE OF SOLUTION.............................................................................73.2 BASIC SYSTEM CHECKLIST........................................................................................................83.3 FUNCTIONAL SYSTEM DESCRIPTION........................................................................................123.4 CONCEPTUAL SYSTEM DESIGN DESCRIPTION..........................................................................16

4. GATE 2: PRELIMINARY SYSTEM DESIGN..........................................................................17

4.1 PRELIMINARY SYSTEM CHECKLIST..........................................................................................174.2 DEVELOPMENT QUALITY DESCRIPTION...................................................................................194.3 PRELIMINARY SYSTEM DESIGN DESCRIPTION.........................................................................204.4 SYSTEM ARCHITECTURE QUALITY DESCRIPTION....................................................................21

5. GATE 3: DETAIL SYSTEM DESIGN........................................................................................23

5.1 DETAIL SYSTEM DESIGN CHECKLIST.......................................................................................235.2 DETAIL SYSTEM DESIGN DESCRIPTION....................................................................................27

5.2.1 Detail System Design – Infrastructure Architecture........................................................275.2.2 Computing Resources Required.......................................................................................285.2.3 Network Access Requirement (Type 1A, Type 1B and Type 2 Hosting)..........................295.2.4 Detail System Design – Application Architecture...........................................................29

6. TECHNICAL ARCHITECTURE DOMAINS...........................................................................30

6.1 NETWORK DOMAIN:.................................................................................................................306.2 APPLICATION DOMAIN:............................................................................................................306.3 DATA DOMAIN:........................................................................................................................306.4 SYSTEMS INTEGRATION DOMAIN:............................................................................................306.5 GROUPWARE DOMAIN:.............................................................................................................306.6 PLATFORM DOMAIN:................................................................................................................306.7 ENTERPRISE MANAGEMENT DOMAIN:.....................................................................................306.8 SECURITY DOMAIN:..................................................................................................................30

7. Appendix A – Service Contract/ Adapter Definition.......................................................................31

Solution Architecture Document Template Version: 1.0 Page 2 of 35Technology Strategy and GovernanceMalta Information Technology Agency

Telephone: (+356) 21234710 Facsimile: (+356) 21234701Web Site: www.mita.gov.mt

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

1. Glossary of termsThis section includes the descriptions of all abbreviations, terms or terminologies used throughout the document.Project Type: New System

A system being submitted for Solution Architecture Assessment for the first time which has never been approved.

Project Type: Upgrade System

An Upgrade of the System refers to an addition/change of any of the component/s, or any other change possible within the existing System Solution Architecture which has already been approved.

Cold Site (In the context of Backups)

A cold site is the most inexpensive type of backup site for an organization to operate. It does not include backed up copies of data and information from the original location of the organization, nor does it include hardware already set up. The lack of hardware contributes to the minimal startup costs of the cold site, but requires additional time following the disaster to have the operation running at a capacity close to that prior to the disaster.

Warm Site(In the context of Backups)

A warm site is, quite logically, a compromise between hot and cold. These sites will have hardware and connectivity already established, though on a smaller scale than the original production site or even a hot site. Warm sites will have backups on hand, but they may not be complete and may be between several days and a week old. An example would be backup tapes sent to the warm site by courier.

Hot Site(In the context of Backups)

A hot site is a duplicate of the original site of the organization, with full computer systems as well as near-complete backups of user data. Real time synchronization between the two sites may be used to completely mirror the data environment of the original site using wide area network links and specialized software. Following a disruption to the original site, the hot site exists so that the organization can relocate with minimal losses to normal operations.

Private Runtime Environment (PRE) Principles

A Private Runtime Environment (PRE) is an environment which enables Contractors to locate their Solution in a segregated environment within premises provided by MITA. Within this environment, the following applies:

(a) MITA will provide the space for the Contractor to install its Solution;

(b) The Contractor will be fully responsible for operating, administering and managing its Solution;

(c) At its discretion, MITA may provide the necessary ICT Computing Resources itself;

The PRE will be governed by the terms of another document (refer to PRE Documentation - https://www.mita.gov.mt/MediaCenter/PDFs/3_TSG-REP-PrivateRuntimeEnvironment_Public-v2.0.pdf); The document outlines the responsibilities of MITA and the Contractor in relation to the PRE.

PSO Public Sector Organisation




https://www.mita.gov.mt/MediaCenter/PDFs/3_TSG-REP-PrivateRuntimeEnvironment_Public-v2.0.pdf

IntroductionThe Solution Architecture Template has been designed to enable Public Sector Organisation (PSO) to provide an increasing amount of detail to the Technology and Systems Governance (TSG) over the life of a project. PSO requesting Project Approval will be required to complete this template, section by section, during the various phases of a project. To facilitate this process, this template has been separated into four sections.

1.1 System Design Sections

Each section of the template must be completed to the extent possible for the Project Approval Gate being requested. It is also understood that in certain situations there might be checklist items which for various reasons might not be possible to be compiled. In this case, the form should be filled in with the following acronyms according to the prescribed scenario.

Acronym Description ScenarioTBD To Be Determined Information requested in a particular section is

not yet available or known at the time of completion of the section. In such a case, when the subsequent section of the document is completed, the information that was previously unavailable must be provided.

NDI Non Disclosed Information Information being requested cannot be disclosed. Typical reasons could include:

o Contractual obligations/ limitations;o Intellectual Property Rights

(Copyright, Patent)o other reason

Note: a valid reason for not providing the information must be clearly stated.

NR Not relevant Information being requested is not relevant to the solution being assessed.

Basic Profile Section: This section of the document is required to be submitted, reviewed, and approved by TSG, prior to receiving Gate 1 (Project Initiation) Project Approval.

Preliminary System Design Section: This section of the document is required to be submitted, reviewed, and approved by TSG, prior to receiving Gate 2 (Planning/Design) Project Approval.

Detailed System Design Section: This section of the document is required to be submitted, reviewed, and approved by TSG, prior to completing Gate 3 (Execute and Build) Project Approval. Normally, this documentation would be submitted as soon as the Detail System Design has been completed.

Update to Detail System Design Section: An update to the detail design is required to be submitted, reviewed, and approved by TSG, prior to receiving Gate 3 (Implementation) Project Approval. Any changes to the system design based on pilot testing must be incorporated. Once this approval has been issued, the Implementation phase may begin.




Gate 1:Project Initiation Review

Gate 2 : Planning / Design Review

Gate 3:Execution/ Build/ Pilot Review

(Pre-Implementation)

Basic Solution Profile Section

Detailed System Design Sector

Preliminary -System Design

Section

Update Solution Architecture

Solution Assessment Gates

1.2 TSG Offers Assistance to Public Sector Organisation

One of the primary services that TSG offers to PSOs is system design review and assistance. Involving TSG as early as possible in the project (e.g. during RFP creation or system design) is a key factor to the overall success of a project. This type of early involvement helps to ensure that the project complies with the necessary standards and policies. It also facilitates Project Approval. If you would like to request TSG assistance, or have any questions concerning the completion of this document, please send an email on [email protected]




mailto:[email protected]

2. System Design Change Log

Any moderate or significant changes to the system 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

Example: New System: MyPassport- This system includes the introduction of biometric passports.

1.0 13/02/2010

Example: Upgrade: MyPassport- Added the use of a new web service.

2.0 30/03/2010




mailto:[email protected]

3. Gate 1: Basic Solution Profile

The Basic Solution Profile Section has been designed to capture only the most essential information required for the Initial Project Approval.

3.1 High Level Business Scope of Solution

Business Context Checklist Business Description(Provide basic information on the purpose of the solution and what business areas the solution must cover. Clearly highlighting Benefits, Assumptions , Dependencies, Risks)

EU Initiative / Obligations __ No __ Yes Which EU law / directive / initiative mandate the creation of the solution?

Mission Criticality (in the context of Government’s business)

Which local law / directive mandate the creation of a solution?

What are the repercussions of not implementing the solution? (Example: Penalties, Disruption to Government’s ICT / Business Strategy. Clearly provide the necessary documentation to substantiate your case)

By when does the solution need to be live / available for use? (Provide reason why)

Monetary Value / Budget Allocated

Capital Expenditure (CAPEX) _______(Euros)(Such as: Procurement , Deployment etc)

Operational Expenditure (OPEX) _______(Euros)(Such as: Maintenance & Support, Recurring License Costs etc)

Kindly also highlight Budget Sources funding the solution:

NOTE: If breakdown of the above values is available, kindly attach with the submission.

Solution Scope ___ International (inter-governmental- Solution which will be shared or is common amongst governments; implemented across EU member states)

___ Government Wide (Interdepartmental - Solution which will be shared or is common amongst local Government departments)

___ Local (Departmental - Solution which will be only used by the specific Government department)




3.2 Basic System 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.

Conceptual System Checklist Responses - Select all that applyProject Type __ New System __ Upgrade System

Delivery of Functionality __ Functionality delivered over time__ Functionality delivered all at once

System Interactions __ Government to Citizen (G2C) Services offered to the Public

__ Government to Business (G2B)Services offered to the third party organizations which are not controlled by the Government

__ Government to Government (G2G)Services intended to be used by Ministries, Government departments and/or entities

__ Government to Other Government (G2OG)Services that will be used by other Governments, such as Other EU member states

List/ Verify that the solution adheres to the ICT Policies/Directives

Such as: o GMICT X 0071:2010 Adopted Specificationso CIMU S0051 Website Standardo CIMU P 0012:2003 Third party Web hosting

services Policy

ICT Policies and Directive can be found at http://ictpolicies.gov.mt.

Highlight any deviations (providing detailed description) to the Policies/ Directives found in the above URL.

Estimated Total Number of Customers Total: __________

By Audience:Citizen: ______ Employee: _____ Business:______ Other:______

Note: For systems were functionality will be delivered over time specify amounts by implementation phase.

Estimated Total Number of Concurrent Customers

Total: _________


Note: For systems were functionality will be delivered over time specify amounts by implementation phase.

The quoted figures should serve as guidelines and should be provided on an estimate basis. The figures are also subjective to the type of application (i.e. whether the solution is a client server application or web based application). Solution Architecture Document Template Version: 1.0 Page 8 of 35

Technology Strategy and GovernanceMalta Information Technology Agency



http://ictpolicies.gov.mt/

Conceptual System Checklist Responses - Select all that applyEstimated Annual Customer Growth Rate Percentage: _________


Note: For modular delivery specify amounts by implementation phase.

Electronic Form

Performance Requirements Section Please list down 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 system handle individual requests, what

a real user would experience) throughput (how many requests the system can handle) concurrency (how many users or threads work simultaneously)Note: Fill as deemed necessary

Production Hours of Operation __ Citizen __ Normal Business Hours (e.g. 8:00 am to 5:00 pm) __ Extended Business Hours (specify): _______________ __ 24 X 7

__ Employee __ Normal Business Hours (e.g. 8:00 am to 5:00 pm) __ Extended Business Hours (specify): _______________ __ 24 X 7

__ Government/Business Partner(s) __ Normal Business Hours (e.g. 8:00 am to 5:00 pm) __ Extended Business Hours (specify): _______________ __ 24 X 7




Conceptual System Checklist Responses - Select all that applyProduction Availability Expectations on a monthly basis

Kindly highlight any peaks and troughs of the service being rendered?e.g. Every end of the month there is a peak due to the license renewal process.

What are the repercussions if the system fails?e.g. The PSO needs to extend the time window for receiving license renewals which results in an increase in cost.

Uptime => Downtime/month (i.e. unplanned)__ 99 (2 Nines) => 7h 30m __ 99.5 => 4h 45m__ 99.9 (3 Nines) => 1h 45m __ 99.99 (4 Nines) => 5m __ 99.999 (5 Nines) => 30s__ Other (specify):

Scheduled Downtime:__ Minutes (specify amount):__________ Hours (specify amount):__________

Service Restoration:__ Minutes (specify amount):__________ Hours (specify amount):__________

MTBF: (Mean Time Between Failure) __ Minutes (specify amount):__________ Hours (specify amount):__________

Note: Please indicate how the SLA shall be monitored

Application Backup Requirements Full Backup: __ Daily __ WeeklyIncremental Backup: __ Hourly __ Daily __ Weekly

Application Recovery Time __ Minutes (specify amount):__________ Hours (specify amount):__________

Solution Delivery Model / Business Model __ as a Service (subscription based)Note: Please refer to Cloud Services check list - https://www.mita.gov.mt/MediaCenter/PDFs/2_SC29-REP-Cloud-Common-Assessment-and-Considerations-v1.0.pdf)

__ Traditional




https://www.mita.gov.mt/MediaCenter/PDFs/2_SC29-REP-Cloud-Common-Assessment-and-Considerations-v1.0.pdf

Conceptual System Checklist Responses - Select all that applyTarget Hosting Environment __ Shared eGovernment Web Hosting Environment managed & supported

by MITA - This applies for existing systems only i.e. solution updates/ upgrades

__ Dedicated Environment at the Government Data Centers managed by MITA – This applies for existing systems only i.e. solution updates/ upgrades. Service Hosting Catalogue TYPE 2 - refer to service hosting catalogue (https://www.mita.gov.mt/MediaCenter/PDFs/1_IMS-GDL-ServiceHostingCatalogue-v1.0.pdf)

__ Dedicated Environment at the Government Data Centers managed by 3rd parties (in line with the PRE principles)

__ Computing resources provided by MITA - Service Hosting Catalogue TYPE 1B - refer to service hosting catalogue (https://www.mita.gov.mt/MediaCenter/PDFs/1_IMS-GDL-ServiceHostingCatalogue-v1.0.pdf)__ Computing resources not provided by MITA - Service Hosting Catalogue TYPE 1A - refer to service hosting catalogue (https://www.mita.gov.mt/MediaCenter/PDFs/1_IMS-GDL-ServiceHostingCatalogue-v1.0.pdf)

3rd Party Supplier Organization:____________NOTE: This is subject to approval i.e. involving business negotiations and appropriate discussions with the respective stakeholders

__ Hosting managed & supported at 3rd parties __Shared __Dedicated Organization providing the hosting:_______________ Organization providing the management & support:_______________ Country where the data shall be residing:________________ Country from where the service shall be rendered:________________

NOTE: If more than one hosting mode is selected please supply more information about the role of each hosting layer




https://www.mita.gov.mt/MediaCenter/PDFs/1_IMS-GDL-ServiceHostingCatalogue-v1.0.pdf




Conceptual System Checklist Responses - Select all that applySystem Usage of Government Shared Services

__ myBills Shared Service handling online government payments.

__ myFormsShared Service for creating electronic forms and the respective workflows for the delivery of citizen centric eServices

__ myAlerts/ mGovShared alerting services used to deliver Short Message Services (SMS) and email notifications.

__ eIDA shared service which allows citizens and businesses to identify themselves via the government’s Web portal or telephone contact centre to securely access any number of available e-Services, regardless of which organization provides the service.

__ CDRShared Service providing access to Corporate Data.

__ Corporate identityA Shared Service for the provision of Identity to the Public Administration.

Kindly highlight any usage peaks of the service/s being consumed

NOTE: For Gate 2 approval the respective service contract that includes the respective service consumption mechanism must be included. (Service Contract Template Appendix A)

System Usage of 3rd Party Service Identify and list any interactions required with 3rd party services in the table below:

Service Name Service Provider

NOTE: For Gate 2 approval the respective service contract that includes the respective service consumption mechanism must be included. (Service Contract Template Appendix A)

3.3 Functional System Description

Provide a diagram (or diagrams) with corresponding narrative that depicts the functional aspects of the application. Corresponding narrative that describes each major functional area of the application must also be supplied. Describe how the system will be used and operated. Describe both the type of users of the system as well as any business interfaces that may be necessary.




Note: The diagram below has been provided for illustrative purposes only. PSOs should delete the diagram provided and supply information specific to the application requesting approval.

Note: Narrative describing the functional design of the application must be provided immediately following the diagram(s).



Financial Management Application (Functional Design)

InternalAgency

Interfaces(e.g Payroll,

And HR)

ExternalAgency

Interfaces(Specify)

PurchasingAccountsPayable

AccountsReceivable

FixedAssets

General Ledger

BankReconciliation

DirectDeposits

Billing Shipping

ReportingCitizens

Business

Employees


Bank Employee (Front office)

Bank Employee (Back office)

Stock Account Admin (Back office)

Customer

Agent

Transaction

Inquiry

Transfer

Deposit

Withdrawal

CustomerIdentification

Office Consultation

Stock Consultation

Manage Stocks

Lock Stock

Modify Stock

Create New Stock Paper

Find Stock

Approve StockBusiness

Find Business

Cancel Business

Stock Debit

Stock TransferStock Business

Stock OrderCollection

Stock Credit

Bank ContactRequest

1

1..*

1..*

«uses»

«uses»

«uses»

«uses»

«uses»

«uses»

«uses»

«uses»

1..*

1

1..*

Stock OrderManagement

Stock Analysis

1..*

1

1..*

«uses»

«extends»

«uses»«uses»

«uses»

«uses»

Bank Database

1..*

1 1..*

1..*

1..*

1..*

1

1..*

Example:

Transaction Use CaseThe transaction use case starts when the customer chooses a transaction type from a menu of options. The customer will be asked to furnish appropriate details (e.g. account(s) involved and amount). The transaction will then be sent to the bank, along with information from the customer's card and the PIN the customer entered.

If the bank approves the transaction, any steps needed to complete the transaction (e.g. dispensing cash or accepting an envelope) will be performed, and then a receipt will be printed. Subsequently the customer will be asked whether he/she wishes to do another transaction.




If the bank reports that the customer's PIN is invalid, the Invalid PIN extension will be performed and then an attempt will be made to continue the transaction. If the customer's card is retained due to too many invalid PINs, the transaction will be aborted, and the customer will not be offered the option of doing another.

If a transaction is cancelled by the customer, or fails for any reason other than repeated entries of an invalid PIN, a screen will be displayed informing the customer of the reason for the failure of the transaction, and then the customer will be offered the opportunity to do another.

The customer may cancel a transaction by pressing the Cancel key as described for each individual type of transaction below. All messages to the bank and responses back are recorded in the ATM's log.

Withdrawal Transaction Use CaseA withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a Euro amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt. (The dispensing of cash is also recorded in the ATM's log.)

A withdrawal transaction can be cancelled by the customer pressing the Cancel key any time prior to choosing the Euro amount.

N.B. The above example is showing only a small part of the functionality of the above use case diagram. This section should include a description of the high level functionality illustrated in the above diagram.




3.4 Conceptual System Design Description

Provide a diagram (or diagrams) with corresponding narrative that depicts an accurate description of the conceptual design for the entire application. The design must document how each of the requirements specified in the functional design will be conceptually accomplished. The conceptual design must align with the Principles, Practices, and Standards that are published in the http://ictpolicies.gov.mt and https://www.mita.gov.mt/page.aspx?pageid=228 portals respectively.


Note: Narrative describing the conceptual design of the application must be provided immediately following the diagram(s).




https://www.mita.gov.mt/page.aspx?pageid=228


4. Gate 2: Preliminary System DesignThe Preliminary System 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.

4.1 Preliminary System Checklist


Preliminary System Checklist Responses – Select all that applyDevelopment Approach __ Commercial Off The Shelf (COTS )

__ Free Libre‘ Open Source Software (FLOSS)__ Commercial Open Source__ Custom / BespokeNote: 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):

_______VersionArchitectural Framework(s) __ STRUTS __ JATO __ JSF

__ Other (specify):Architectural Pattern(s) __ MVC __ Factory __ Controller __ Data Access Object

__ Other (specify):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):




Preliminary System Checklist Responses – Select all that applySystem 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:e.g. Solution Integrated authentication using login and password stored in the databasee.g. Solution Integrated authentication using login and password via database accounts stored in the RDBMSe.g. Solution Integrated authentication using certificate based authentication via accounts stored in the local directory service.e.g. Providing local authentication to 3rd parties via claims based authentication using WS-Federation Passive Requestor Profilee.g. Using eID or the Government Public Administration Identity Services

Secure transport :e.g. SSL/TLS, IPSEC

Secure Storage: e.g. Data Encryption - __ Column __ Row __ Table __ Database using AES encryptione.g. Cookie Encryption using AES encryption

__ 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/





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

PortabilityThe ability for a solution to be migrated/ installed on a different environment other then the original one, without the need of any code changes.

MaintainabilityEase of extending the solution functionality, fixing of errors etc.

ExtensibilityThe ability for the solution to be extended with ease and with minor modifications (future proof solution).

SupportabilityThe 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-usabilityThe ability to use modified or unmodified solution components (subroutines etc.) in other solutions.




4.3 Preliminary System 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/page.aspx?pageid=228 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.


Note: Narrative describing the preliminary design of the application must be provided immediately following the diagram(s).






4.4 System 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 system handles individual requests in terms of user experience. Throughput: how many requests the system 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 applicableSecurity Authentication: The substantiation of the identity of a person or entity related to the system 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 system was used in accordance with stated security policies.

Assurance: The ability to test and prove that the system 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 system, and add or change the persons or entities related to the system.

List down the mechanism/s that the solution uses to achieve/ support the above mentioned factors IntegrityThe 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 factorsReliabilityThe ability for a system 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 factorsAvailabilityThe ability of the system to function without service interruption or depletion despite abnormal or malicious events.

List down the mechanism/s that the solution uses to achieve/ support the above mentioned factorsScalabilityA 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.




List down the mechanism/s that the solution uses to achieve/ support the above mentioned factorsManageabilityThe 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 factorsServiceabilityThe 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 factorsRecoverabilityThe 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




5. Gate 3: Detail System Design

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

5.1 Detail System Design Checklist


Detail System Checklist Responses – Select all that applyClient Platform Information __ Standard Desktop

Refer to Desktop Software and Configuration standard - GMICT S 0002:2009; Desktop Hardware standard - GMICT S 0001:2007

__ Non Standard Desktopo Type (PDA, Smartphone etc.) __________o OS (Linux, Android, Palm etc.) __________

OS Version __________

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

Client Footprint by Platform Specify size of footprint in KB or MB: __________

This information will serve as an indication in case the application needs to be virtualised/ streamed.

Client Connection Speed Specify bandwidth in kbps or mbps:Minimum: _____Recommended: ________

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

Client Richness __ Browser Based__ Rich Internet (AJAX, Flash etc.)

__ Rich Client




Detail System Checklist Responses – Select all that applyBrowser Support The solution must be compatible and support the browser/s identified in the

Desktop Software and Configuration standard - GMICT S 0002:2009).

__ Other (specify product and versions):

Presentation - Client Side Languages __ HTML __ DHTML __ XML __ XHTML__ VB.NET __C# __ Flash__ Java ApplTSG __ Java __ JVM (specify details):__ JavaScript __ VBScript__ C++__ Other (specify):

Application State __ Cookies: __ Non-Persistent Cookies __ Persistent Cookies__ Session Ids __ State Stored in Hidden Fields __ Other (specify):

Web Server Location __ Public Facing __ Internal FacingWeb Server Operating System __ Windows __ Linux __ Unix __ Other (specify):

Specify Version:Web Server Software __ Apache __ Microsoft __ Sun __ Oracle__ Other (specify):

Specify Edition and Version:Web Server - High Availability Load Balanced: __ Yes __ No

__ Other (specify):Web Server - Specifications Rollout Configuration:

Number of Servers: __ CPUs/Server: __ CPU Type: _________ CPU Speed: _____ Amount of RAM: ____

Processor Architecture: __ 64 Bit __ 32 Bit

Maximum Configuration: Number of Servers: __ CPUs/Server: __ CPU Type: __________ CPU Speed: _____ Amount of RAM: ____

For PRE hosting; additional information is required (refer to PRE Documentation - https://www.mita.gov.mt/MediaCenter/PDFs/3_TSG-REP-PrivateRuntimeEnvironment_Public-v2.0.pdf)






Detail System Checklist Responses – Select all that applyPresentation – Server Side Languages __ ASP.NET __ VB.NET __C#

__ JSP __ Servlets __ Java __ JVM (specify details):__ Server Side Includes (SSI)__ C++__ Other (specify):

Application Server Operating System __ Windows __ Linux __ Unix __ Other (specify):Specify Version:

Application Server Software __ Microsoft __ IBM __ Sun __ Oracle __ BEA __ Other (specify):Specify Edition and Version:

Application Server – High Availability RAID Supported: __ Yes __ NoSAN Supported: __ Yes __ NoMirroring Supported: __ Yes __ NoClustering Supported: __ Yes __ NoGrid/On Demand Supported: __ Yes __ No__ Other (specify):

Application Server - Specifications Rollout Configuration: Number of Servers: __ CPUs/Server: __ CPU Type: _________ CPU Speed: _____ Amount of RAM: ____Processor Architecture: __ 64 Bit __ 32 BitMaximum Configuration: Number of Servers: __ CPUs/Server: __ CPU Type: __________ CPU Speed: _____ Amount of RAM: ____


Virtualization Technologies ___ Server Virtualization: Vendor:_____________ Storage Virtualization: Vendor:_____________ Application Virtualization: Vendor:_____________ VDI: Vendor:_____________ Other: Vendor:__________

Business Rule – Application Languages __ VB.NET __C# __ Java (J2SE) __ Java/EJB (J2EE) __ JVM (specify details):__ C++__ Other (specify):

Database Server Operating System __ Windows __ Linux __ Unix __ Other (specify):Specify Version:

Database Server Software __ Microsoft __ IBM __ Oracle __ Other (specify):Specify Version:






Detail System Checklist Responses – Select all that applyDatabase Server – High Availability RAID Supported: __ Yes __ No

SAN Supported: __ Yes __ NoMirroring Supported: __ Yes __ NoClustering Supported: __ Yes __ NoGrid/On Demand Supported: __ Yes __ No___ Other (specify):

Database Server - Specifications Rollout Configuration: Number of Servers: __ CPUs/Server: __ CPU Type: _________ CPU Speed: _____ Amount of RAM: ____Processor Architecture: __ 64 Bit __ 32 BitMaximum Configuration: Number of Servers: __ CPUs/Server: __ CPU Type: __________ CPU Speed: _____ Amount of RAM: ____


Data Access – Connectivity Methods __ ADO.NET __ ODBC __ OLE/DB __ JDBC __ JDO__ DB2 Connect __ Other (specify):

SQL Languages __ T/SQL __ PL/SQL __ Other (specify):

Use of SQL ANSI 92/99 (and appropriate successors) compliant constructsStored Procedures Utilization __ No

__ Yes __ 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.






5.2 Detail System 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 system. 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/page.aspx?pageid=228 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.

5.2.1 Detail System Design – Infrastructure Architecture








Note: Narrative describing the detail design of the application must be provided immediately following the diagram(s).

5.2.2 Computing Resources Required

5.2.2.1 Type 1A Hosting – Hardware Provided By Solution Provider

Data Centre Facilities

Query ResponseNumber of Physical Servers Rack Space required (in rack Height Units)Air Flow Direction (e.g. Front-bottom-up, etc)Total Heat Dissipation (Btu/Hr)Total Power Consumption (kVA)Operating Temperature (degrees Celsius)

5.2.2.2 Type 1B Hosting – Computing Resources Provided by MITA

Virtualised Environment Requirement

Query ResponseNumber of Guests

Query for each Guest ResponseCPU (GHZ)RAM (GB)Hard disk space (GB)Number of Network interfacesBandwidth needed for each interface (KBps)Frequency of backups(daily/weekly/monthly)Can server be shut down during the backup process? (Yes/No)Operating System (Windows Linux x64/x86)Database Management Server (e.g. SQL; Oracle( if any)

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

Access Required for each Guest

Access required

Access required

TCP/UDP port

Access required both ways




from toAnti Virus (updates of AV)Netbios OS Updates DNS Remote support (RDP/SSH) Internet Access HTTP HTTPS SMTP POP3 IMAP IMAPS

5.2.4 Detail System Design – Application Architecture

Provide a detailed system design reflecting the Presentation Layer, Business Layer and Data Access Layer.




6. Technical Architecture DomainsPlease provide any significant architectural information (that has not been previously provided) for this application. 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.

6.1 Network Domain:

[Specify any additional information]

6.2 Application Domain:


6.3 Data Domain:


6.4 Systems Integration Domain:


6.5 Groupware Domain:


6.6 Platform Domain:


6.7 Enterprise Management Domain:


6.8 Security Domain:





7. Appendix A – Service Contract/ Adapter Definition

Section 1 - Functional

1. Consumption Information

How is this service consumed?

The services 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 SMD.

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

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

2. Interfaces providedTechnical information on the accessibility of the Interfaces provided

3. List of FunctionalityList of functionality that is available within the interfaces defined in Section 3 Property 2

4. StandardsThe following is a table with a list of standards relevant to the provision of this service.

Standard Information

SMTP http://tools.ietf.org/html/rfc5321

TLS/SSL http://tools.ietf.org/html/rfc5246

DNS http://www.ietf.org/rfc/rfc1035.txt

SNMP http://www.snmp.com/protocol/

5. Location of DocumentationThe physical/virtual location of the technical design, including interfacing documentation and architecture blueprint of this adapter




http://www.snmp.com/protocol/

http://www.ietf.org/rfc/rfc1035.txt

http://tools.ietf.org/html/rfc5246

http://tools.ietf.org/html/rfc5321

Section 2 - Other terms

1. TransactionalHow does this adapter support transaction, provide for compensation, or does not provide transactional facility at all

2. Service Level Terms and ConditionsThe Service Level Agreements (SLA) and other terms and conditions related to the consumption of this service

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.

3. Quality of ServiceWhat are the quality checks that were carried out during the design, development and deployment of this adapter?

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.

4. Auditing InformationWhat are the auditing mechanisms in place, if available at all, including the data elements that are recorded for auditing purposes? Include the Data Protection measures that are in place according to GMICT policy and Legislation

5. Defined processesList the processes that are available in order to apply for usage, disconnection or modifications of this adapter, as well as processes related to the consumer accessibility to the adapter.

Requests for consumption of this adapter are controlled by MITA SMD. A change request is required to open port 25 from the Private Runtime Environment to the service as defined under interfaces.

Requests for access to the adapter are identified through the architecture blueprint to be presented according to Architecture Blueprint requirements available at https://www.mita.gov.mt/page.aspx?pageid=228. Project Manager is responsible to trigger change management process.




Section 3 - Responsibilities

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

Responsible Role Organisation-Team

Accountable Role Organisation-Team

Consultative Role Organisation-Team

Informative Role Organisation-Team




Documents

Solution Architecture Template - MITA1 … · Web viewThe Solution Architecture Template has been designed to enable Public Sector ... To facilitate this process, ... word processing