Solution Architecture Template

Solution Architecture Submission for <Project Name

Project NameSolution Architecture

Technical Document

Date: dd/mmm/yyyy

Version:nn.nn

Company Name / Company Logo

Solution Architecture DocumentTemplate Version: 1.0

Technology Strategy and Governance

Malta Information Technology Agency

Telephone: (+356) 21234710 Facsimile: (+356) 2123

Web Site:

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.Glossary of terms

Introduction

1.1System Design Sections

1.2TSG Offers Assistance to Public Sector Organisation

2.System Design Change Log

3.Gate 1: Basic Solution Profile

3.1High Level Business Scope of Solution

3.2Basic System Checklist

3.3Functional System Description

3.4Conceptual System Design Description

4.Gate 2: Preliminary System Design

4.1Preliminary System Checklist

4.2Development Quality Description

4.3Preliminary System Design Description

4.4System Architecture Quality Description

5.Gate 3: Detail System Design

5.1Detail System Design Checklist

5.2Detail System Design Description

5.2.1Detail System Design – Infrastructure Architecture

5.2.2Computing Resources Required

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

5.2.4Detail System Design – Application Architecture

6.Technical Architecture Domains

6.1Network Domain:

6.2Application Domain:

6.3Data Domain:

6.4Systems Integration Domain:

6.5Groupware Domain:

6.6Platform Domain:

6.7Enterprise Management Domain:

6.8Security Domain:

7.Appendix A – Service Contract/ Adapter Definition

1.Glossary of terms

This 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 RuntimeEnvironment (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 toPRE Documentation- ); The document outlines the responsibilities of MITA and the Contractor in relation to the PRE.
PSO / Public Sector Organisation

Introduction

The 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 foursections.

1.1System 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 reasonsmight not be possible to be compiled. In this case, the form should be filled in with the following acronymsaccording to the prescribed scenario.

Acronym / Description / Scenario
TBD / 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:

• Contractual obligations/ limitations;
• Intellectual Property Rights (Copyright, Patent)
• 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 ProfileSection: 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.

Solution Assessment Gates

1.2TSG 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

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

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

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.1High 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.2Basic 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 apply
Project 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:

• GMICT X 0071:2010 Adopted Specifications
• CIMU S0051 Website Standard
• CIMU P 0012:2003 Third party Web hosting services Policy

/ ICT Policies and Directive can be found at
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: ______
By Audience:
Citizen: ______Employee: _____ Business:______Other:______
Note: For systems were functionality will be delivered over time specify amounts by implementation phase.
Estimated Annual Customer Growth Rate / Percentage: ______
By Audience:
Citizen: ______Employee: _____ Business:______Other:______
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
Production 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) => 7h30m
__ 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 __ Weekly
Incremental 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 -
__ Traditional
Target 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(
__ 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(
__ Computing resources not provided by MITA - Service Hosting Catalogue TYPE 1A - refer to service hosting catalogue(
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
Organizationproviding 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
System Usage of Government Shared Services / __ myBills
Shared Service handling online government payments.
__ myForms
Shared Service for creating electronic forms and the respective workflows for the delivery of citizen centric eServices
__ myAlerts/ mGov
Shared alerting services used to deliver Short Message Services (SMS) and email notifications.
__ eID
A shared service which allows citizens and businesses to identify themselves via the government’s Webportal or telephone contact centre to securely access any number of available e-Services, regardlessof which organization provides the service.
__ CDR
Shared Service providing access to Corporate Data.
__ Corporate identity
A 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.3Functional 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. PSOsshould 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).

Example:

Transaction Use Case

The 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. Subsequentlythe 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.