1 Tsg Tpl Solution Architecture Template v1.0

8/12/2019 1 Tsg Tpl Solution Architecture Template v1.0

1/35

Solution Architecture

Technical Document

Date: Version:


2/35

Solution Architecture Submission for

Solution Architecture Document Template Version: 1.0Technology Strategy and o!ernance

"alta #nformation Technology Agency

Telephone: $%&'() *1*&+,10 -acsimile: $%&'() *1*&

eb Site: ///.mita.go!.mt
http://www.mita.gov.mt/http://www.mita.gov.mt/


3/35

Solution Architecture Submission for

Submission Details

Project Name:

Submission Contact Name: Ministry / Department /

Company

Submission Contact Title:

Submission Contact Details: / /

Project Completion Date:

Supplier: Supplier ContactPerson:

Supplier Contact Details: / /

Client Name: Ministry / Department /

Company

Client Contact Details: / /


4/35

Table of Contents

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

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

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

1.1 SYSTEMDESIGNSECTIONS...............................................................................................................4

1.2 TSG OFFERSASSISTANCETOPUBLICSECTORORGANISATION .....................................................5

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

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

3.1 HIGHLEVELBUSINESSSCOPEOFSOLUTION...................................................................................7

3.2 BASICSYSTEMCHECKLIST..............................................................................................................8

3.3 FUNCTIONALSYSTEMDESCRIPTION..............................................................................................123.4 CONCEPTUALSYSTEMDESIGNDESCRIPTION ...............................................................................16

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

4.1 PRELIMINARYSYSTEMCHECKLIST................................................................................................17

4.2 DEVELOPMENTUALITYDESCRIPTION.........................................................................................1!

4.3 PRELIMINARYSYSTEMDESIGNDESCRIPTION................................................................................2"

4.4 SYSTEMARCHITECTUREUALITYDESCRIPTION..........................................................................21

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

5.1 DETAILSYSTEMDESIGNCHECKLIST.............................................................................................23

5.2 DETAILSYSTEMDESIGNDESCRIPTION..........................................................................................27

5.2.1 Detail System Design !n"rastructure #rchitecture..............................................................2$

5.2.2 Computing %esources %e&uire' ............................................................................................2(5.2.) Net*or+ #ccess %e&uirement ,-ype 1# -ype 1 an' -ype 2 0osting.................................2

5.2.3 Detail System Design #pplication #rchitecture .................................................................2

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

6.1 NET#ORKDOMAIN$.......................................................................................................................3"

6.2 APPLICATIONDOMAIN$..................................................................................................................3"

6.3 DATADOMAIN$..............................................................................................................................3"

6.4 SYSTEMSINTEGRATIONDOMAIN$..................................................................................................3"

6.5 GROUP#AREDOMAIN$...................................................................................................................3"

6.6 PLATFORMDOMAIN$......................................................................................................................3"

6.7 ENTERPRISEMANAGEMENTDOMAIN$...........................................................................................3"

6.8 SECURITYDOMAIN$........................................................................................................................3"

7. APPENDIX A SER!ICE CONTRACT" ADAPTER DEFINITION.........................................31

Solution Architecture Document Template Version: 1.0 age * of &'

Technology Strategy and o!ernance


Telephone: $%&'() *1*&+,10 -acsimile: $%&'() *1*&+,01



5/35

1. Glossary of terms

This section includes the descriptions of all abbre!iations terms or terminologies usedthroughout the document.

Solution Architecture Document Template Version: 1.0 age & of &'





Project Type:

New System

A system being submitted for Solution Architecture Assessment forthe first time /hich has ne!er been appro!ed.

Project Type:

p!ra"e System

An 2pgrade of the System refers to an addition3change of any of thecomponent3s or any other change possible /ithin the e4istingSystem Solution Architecture /hich has already been appro!ed.

Col" Site

(In the context of ac!up"#

A cold site is the most ine4pensi!e type of bac5up site for anorgani6ation to operate. #t does not include bac5ed up copies of dataand information from the original location of the organi6ation nordoes it include hard/are already set up. The lac5 of hard/arecontributes to the minimal startup costs of the cold site but re7uiresadditional time follo/ing the disaster to ha!e the operation runningat a capacity close to that prior to the disaster.

#arm Site


A /arm site is 7uite logically a compromise bet/een hot and cold.These sites /ill ha!e hard/are and connecti!ity already establishedthough on a smaller scale than the original production site or e!en ahot site. arm sites /ill ha!e bac5ups on hand but they may not becomplete and may be bet/een se!eral days and a /ee5 old. Ane4ample /ould be bac5up tapes sent to the /arm site by courier.

$ot Site


A hot site is a duplicate of the original site of the organi6ation /ithfull computer systems as /ell as near8complete bac5ups of userdata. 9eal time synchroni6ation bet/een the t/o sites may be usedto completely mirror the data en!ironment of the original site using

/ide area net/or5 lin5s and speciali6ed soft/are. -ollo/ing adisruption to the original site the hot site e4ists so that theorgani6ation can relocate /ith minimal losses to normal operations.

Pri%ate &untime'n%ironment (P&')Principles

A ri!ate 9untime n!ironment $9) is an en!ironment /hichenables ;ontractors to locate their Solution in a segregateden!ironment /ithin premises pro!ided by "#TA. ithin thisen!ironment the follo/ing applies:

$a) "#TA /ill pro!ide the space for the ;ontractor to install itsSolution

$b) The ;ontractor /ill be fully responsible for operatingadministering and managing its Solution

$c) At its discretion "#TA may pro!ide the necessary #;T;omputing 9esources itself

The 9 /ill be go!erned by the terms of another document $referto P$% &ocumentation '%&&'(//)))*mita*+o,*mt/Me-iaCenter/P&."/0TS1'$%P'Pri,ate$untime%n,ironment0Public',2*3*p-f) The documentoutlines the responsibilities of "#TA and the ;ontractor in relation tothe 9.

PS* ublic Sector =rganisation
http://www.mita.gov.mt/https://www.mita.gov.mt/MediaCenter/PDFs/3_TSG-REP-PrivateRuntimeEnvironment_Public-v2.0.pdfhttps://www.mita.gov.mt/MediaCenter/PDFs/3_TSG-REP-PrivateRuntimeEnvironment_Public-v2.0.pdfhttps://www.mita.gov.mt/MediaCenter/PDFs/3_TSG-REP-PrivateRuntimeEnvironment_Public-v2.0.pdfhttp://www.mita.gov.mt/


6/35

+ntro"uction

The Solution Architecture Template has been designed to enable ublic Sector =rganisation$S=) to pro!ide an increasing amount of detail to the Technology and Systems o!ernance$TS) o!er the life of a proect. S= re7uesting roect Appro!al /ill be re7uired to completethis template section by section during the !arious phases of a proect. To facilitate this

process this template has been separated into four sections.

1.1 System Desi!n Sections

ach section of the template must be completed to the e4tent possible for the roectAppro!al ate being re7uested. #t is also understood that in certain situations there might bechec5list items /hich for !arious reasons might not be possible to be compiled. #n this casethe form should be filled in /ith the follo/ing acronyms according to the prescribed scenario.

,cronym Description Scenario

T-D To -e Determine" #nformation re7uested in a particular section is

not yet a!ailable or 5no/n at the time ofcompletion of the section. #n such a case/hen the subse7uent section of the documentis completed the information that /aspre!iously una!ailable must be pro!ided.

ND+ Non Disclose" +nformation #nformation being re7uested cannot bedisclosed. Typical reasons could include:

o ;ontractual obligations3 limitations

o #ntellectual roperty 9ights

$Cop4ri+ht5 Patent)

o other rea"on

Note a ,ali- rea"on for not pro,i-in+ the information mu"tbe clearl4 "tate-*

N& Not rele%ant #nformation being re7uested is not rele!ant tothe solution being assessed.

-asic Profile Section:This section of the document is re7uired to be submitted

re!ie/ed and appro!ed by TS prior to recei!ing ate 1 $roect #nitiation) roectAppro!al.

Preliminary System Desi!n Section:This section of the document is re7uired to be

submitted re!ie/ed and appro!ed by TS prior to recei!ing ate *$lanning3Design) roect Appro!al.

Detaile" System Desi!n Section: This section of the document is re7uired to besubmitted re!ie/ed and appro!ed by TS prior to completing ate & $4ecute and?uild) roect Appro!al. @ormally this documentation /ould be submitted as soon asthe Detail System Design has been completed.

p"ate to Detail System Desi!n Section: An update to the detail design is

re7uired to be submitted re!ie/ed and appro!ed by TS prior to recei!ing ate &$#mplementation) roect Appro!al. Any changes to the system design based on pilottesting must be incorporated. =nce this appro!al has been issued the#mplementation phase may begin.

Solution Architecture Document Template Version: 1.0 age + of &'






7/35

Solution ,ssessment Gates

1. TSG *ffers ,ssistance to Public Sector *r!anisation

=ne of the primary ser!ices that TS offers to S=s is system design re!ie/ and assistance.#n!ol!ing TS as early as possible in the proect $e.g. during 9- creation or system design)is a 5ey factor to the o!erall success of a proect. This type of early in!ol!ement helps toensure that the proect complies /ith the necessary standards and policies. #t also facilitatesroect Appro!al. #f you /ould li5e to re7uest TS assistance or ha!e any 7uestionsconcerning the completion of this document please send an email on eau.mitago!.mt

Solution Architecture Document Template Version: 1.0 age ' of &'




mailto:[email protected]://www.mita.gov.mt/mailto:[email protected]://www.mita.gov.mt/


8/35

. System Desi!n Can!e 0o!

,ny mo"erate or si!nificant can!es to te system "esi!n must be resubmitte" to TSfor re!ie/ and appro!al prior to ma5ing any actual implementation change$s). #n most casesthe re!ie/ and appro!al of any changes /ould be performed internally /ithin TS.

@otes:

1. se of a wor" processin! automate" can!e tracin! feature is re2uire" /henresubmitting this document in order to simplify the re!ie/ and appro!al process. =nce a!ersion of the document has been appro!ed then that !ersion of the document should besa!ed for archi!al purposes. rior to submitting a ne/ !ersion of the document all priortrac5ed changes should be accepted. This process for resubmission can then berepeated as many times as necessary until the final appro!al has been issued.

*. 3ailure to resubmit can!es for re%iew an" appro%al could result in arecommendation by TS that the proect appro!al status be reconsidered. +f tere are

any 2uestions as to weter or not a can!e is substanti%e enough to /arrant re!ie/and appro!al please send an email on eau.mitago!.mtfor clarification.

&. Maintain a summary of can!esin the table belo/.

Can!e 0o! Summary 4 Description

(3or instructional purposes e5amples a%e beenpro%i"e")

6ersion Date

Example: New System:

M4Pa""port' Thi" "4"tem inclu-e" the intro-uction ofbiometric pa""port"*

6*3 6/32/2363

Example: Upgrade:

M4Pa""port' 7--e- the u"e of a ne) )eb "er,ice*

2*3 3/3/2363

Solution Architecture Document Template Version: 1.0 age ( of &'




mailto:[email protected]://www.mita.gov.mt/mailto:[email protected]://www.mita.gov.mt/


9/35

7. Gate 1: -asic Solution Profile

The ?asic Solution rofile Section has been designed to capture only the most essentialinformation re7uired for the #nitial roect Appro!al.

7.1 $i! 0e%el -usiness Scope of Solution

Solution Architecture Document Template Version: 1.0 age , of &'





-usiness Conte5t Ceclist

Business Description

(Provide basic information on the purpose of the solution and what business areas the solution must cover. Clearly highlighting Benefits,Assumptions , Dependencies, Riss!

EU Initiative / Obligations __ No __ Yes

Which EU law / directive / initiative andate the creation o! the solution"

#ission $riticalit% &in theconte't o! (overnent)sbusiness*

Which local law / directive andate the creation o! a solution"

What are the repercussions o! notipleenting the solution"

("#ample$ Penalties, Disruption to %overnment&s 'C ) Business *trategy. Clearly provide thenecessary documentation to substantiate your case!

B% when does the solution need to be live / available !or use"

(Provide reason why!

#onetar% +alue / Budget,llocated

$apital E'penditure &$,-E.* _______&Euros*

(*uch as$ Procurement , Deployment etc!

Operational E'penditure &O-E.* _______&Euros*

(*uch as$ +aintenance *upport, Recurring -icense Costs etc!

indl% also highlight Budget 0ources !unding the solution1

NOT% If brea!-o)n of the abo,e ,alue" i" a,ailable5 !in-l4 attach )ith the"ubmi""ion*

0olution 0cope ___ International

(intergovernmental *olution which will be shared or is common amongst governments/ implementedacross "0 member states!

___ (overnent Wide

('nterdepartmental *olution which will be shared or is common amongst local %overnmentdepartments!

___ 2ocal

(Departmental *olution which will be only used by the specific %overnment department!


10/35

7. -asic System Ceclist

Disclaimer: ,ny tecnolo!ies liste" below a%e been pro%i"e" solely for con%enience8te information pro%i"e" is not inten"e" to be e5austi%e nor "oes it in"icate pro"ucten"orsement by TSG.

Conceptual System Ceclist &esponses 9 Select all tat apply

-ro3ect 4%pe __ New 0%ste __ Upgrade 0%ste

Deliver% o! 5unctionalit% __ 5unctionalit% delivered over tie

__ 5unctionalit% delivered all at once

0%ste Interactions __ (overnent to $iti6en &(7$*

*ervices offered to the Public

__ (overnent to Business &(7B*

*ervices offered to the third party organi1ations which are not controlled by the %overnment

__ (overnent to (overnent &(7(*

*ervices intended to be used by +inistries, %overnment departments and)or entities

__ (overnent to Other (overnent &(7O(*

*ervices that will be used by other %overnments, such as 2ther "0 member states

2ist/ +eri!% that the solution adheres to the I$4-olicies/Directives

*uch as$

o %+'C 3 4456$7464 Adopted *pecifications

o C'+0 *4486 9ebsite *tandard

o C'+0 P 4467$744: hird party 9eb hosting

services Policy

I$4 -olicies and Directive can be !ound at http1//ictpolicies8gov8t8

9ighlight an% deviations &providing detailed description* to the -olicies/Directives !ound in the above U:28

Estiated 4otal Nuber o! $ustoers 4otal1 __________

B% ,udience1

$iti6en1 ______ Eplo%ee1 _____ Business1______ Other1______

;ote$ ective to the type of application (i.e. whether the solution is a client server application or web basedapplication!.

Solution Architecture Document Template Version: 1.0 age B of &'




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


11/35



Estiated 4otal Nuber o! $oncurrent

$ustoers 4otal1 _________

B% ,udience1

$iti6en1 ______ Eplo%ee1 _____ Business1______ Other1______

;ote$ > a to ?1>> p*

__ E'tended Business 9ours &speci!%*1 _______________

__ 7@ . A

__ (overnent/Business -artner&s*

__ Noral Business 9ours &e8g8 =1>> a to ?1>> p*

__ E'tended Business 9ours &speci!%*1 _______________

__ 7@ . A

Solution Architecture Document Template Version: 1.0 age C of &'






12/35



-roduction ,vailabilit% E'pectations on a

onthl% basis

indl% highlight an% peas and troughs o! the service being rendered"

e.g. "very end of the month there is a pea due to the license renewalprocess.

What are the repercussions i! the s%ste !ails"

e.g. he P*2 needs to e#tend the time window for receiving licenserenewals which results in an increase in cost.

Uptie C Downtie/onth &i8e8 unplanned*

__ &7 Nines* C 7h 30m

__ 8? C @h @?

__ 8 &F Nines* C 1h 45m__ 8 &@ Nines* C 5m

__ 8 &? Nines* C 30s

__ Other &speci!%*1

0cheduled Downtie1

__ #inutes &speci!% aount*1________

__ 9ours &speci!% aount*1__________

0ervice :estoration1



#4B51 ean 4ie Between 5ailure*



;ote$ Please indicate how the *-A shall be monitored

,pplication Bacup :e;uireents 5ull Bacup1

__ Dail% __ Weel%

Increental Bacup1

__ 9ourl% __ Dail% __ Weel%

,pplication :ecover% 4ie __ #inutes &speci!% aount*1________


0olution Deliver% #odel / Business #odel __ as a 0ervice &subscription based*

;ote$ Please refer to Cloud *ervices chec listhttps$))www.mita.gov.mt)+ediaCenter)PD


13/35



4arget 9osting Environent __ 0hared e(overnent Web 9osting Environent anaged G supported

b% #I4, H This applies for existin s!stems onl! i"e" solution up#ates$upra#es

__ Dedicated Environent at the (overnent Data $enters anaged b%#I4, This applies for existin s!stems onl! i"e" solution up#ates$upra#es" Ser%ice &ostin 'ataloue T()* + , refer toservicehosting catalogue(https$))www.mita.gov.mt)+ediaCenter)PD


14/35



0%ste Usage o! (overnent 0hared

0ervices

.. m!-ills

*hared *ervice handling online government payments.

.. m!/orms

*hared *ervice for creating electronic forms and the respective worflowsfor the delivery of citi1en centric e*ervices

.. m!Alerts$ mo%*hared alerting services used to deliver *hort +essage *ervices (*+*!and email notifications.

.. eD

A shared service which allows citi1ens and businesses to identifythemselves via the government&s 9eb portal or telephone contact centre tosecurely access any number of available e*ervices, regardless of whichorgani1ation provides the service.

.. 'D2

*hared *ervice providing access to Corporate Data.

.. 'orporate i#entit!

A *hared *ervice for the provision of 'dentity to the Public Administration.

indly highlight any usage peas of the service)s being consumed

@=T: -or ate * appro!al the respecti!e ser!ice contractthat includes the respecti!e ser!ice consumption mechanismmust be included. $Ser!ice ;ontract Template Appendi4 A)

0%ste Usage o! Frd-art% 0ervice #dentify and list any interactions re7uired /ith &rd partyser!ices in the table belo/:

Ser%ice ame Ser%ice )ro%i#er

@=T: -or ate * appro!al the respecti!e ser!ice contractthat includes the respecti!e ser!ice consumption mechanismmust be included. $Ser!ice ;ontract Template Appendi4 A)

7.7 3unctional System Description

ro!ide a diagram $or diagrams) /ith corresponding narrati!e that depicts the functionalaspects of the application. ;orresponding narrati!e that describes each maor functional area

Solution Architecture Document Template Version: 1.0 age 1* of &'






15/35

of the application must also be supplied. Describe ho/ the system /ill be used and operated.Describe both the type of users of the system as /ell as any business interfaces that may benecessary.

Note: Te "ia!ram below as been pro%i"e" for illustrati%e purposes only. PS*ssoul" "elete te "ia!ram pro%i"e" an" supply information specific to te applicationre2uestin! appro%al.

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

Solution Architecture Document Template Version: 1.0 age 1& of &'





/inancial anaement Application

&5unctional Design*

Internal

,genc%

Inter!aces

&e8g -a%roll

,nd 9:*

E'ternal

,genc%

Inter!aces

&0peci!%*

-urchasing,ccounts

-a%able

,ccounts

:eceivable

5i'ed

,ssets

(eneral 2edger

Ban

:econciliation

Direct

Deposits

Billing 0hipping

:eporting$iti6ens

Business

Eplo%ees


16/35

'5ample:

Transaction 2se ;ase

The transaction use case starts /hen the customer chooses a transaction type from a menuof options. The customer /ill be as5ed to furnish appropriate details $e.g. account$s) in!ol!edand amount). The transaction /ill then be sent to the ban5 along /ith information from thecustomers card and the #@ the customer entered.

#f the ban5 appro!es the transaction any steps needed to complete the transaction $e.g.dispensing cash or accepting an en!elope) /ill be performed and then a receipt /ill beprinted. Subse7uently the customer /ill be as5ed /hether he3she /ishes to do anothertransaction.

Solution Architecture Document Template Version: 1.0 age 1+ of &'






17/35

#f the ban5 reports that the customers #@ is in!alid the #n!alid #@ e4tension /ill beperformed and then an attempt /ill be made to continue the transaction. #f the customerscard is retained due to too many in!alid #@s the transaction /ill be aborted and thecustomer /ill not be offered the option of doing another.

#f a transaction is cancelled by the customer or fails for any reason other than repeatedentries of an in!alid #@ a screen /ill be displayed informing the customer of the reason forthe failure of the transaction and then the customer /ill be offered the opportunity to doanother.

The customer may cancel a transaction by pressing the ;ancel 5ey as described for eachindi!idual type of transaction belo/. All messages to the ban5 and responses bac5 arerecorded in the AT"s log.

ithdra/al Transaction 2se ;ase

A /ithdra/al transaction as5s the customer to choose a type of account to /ithdra/ from

$e.g. chec5ing) from a menu of possible accounts and to choose a uro amount from a menuof possible amounts. The system !erifies that it has sufficient money on hand to satisfy there7uest before sending the transaction to the ban5. $#f not the customer is informed andas5ed to enter a different amount.) #f the transaction is appro!ed by the ban5 the appropriateamount of cash is dispensed by the machine before it issues a receipt. $The dispensing ofcash is also recorded in the AT"s log.)

A /ithdra/al transaction can be cancelled by the customer pressing the ;ancel 5ey any timeprior to choosing the uro amount.

N.-.The abo!e e4ample is sho/ing only a small part of the functionality of the abo!e usecase diagram. This section should include a description of the high le!el functionality

illustrated in the abo!e diagram.

Solution Architecture Document Template Version: 1.0 age 1' of &'






18/35

7. Conceptual System Desi!n Description

ro!ide a diagram $or diagrams) /ith corresponding narrati!e that depicts an accurate

description of the conceptual design for the entire application. The design must documentho/ each of the re7uirements specified in the functional design /ill be conceptuallyaccomplished. The conceptual design must align /ith the rinciples ractices andStandards that are published in the http:33ictpolicies.go!.mt andhttps:33///.mita.go!.mt3page.asp4EpageidF**B portals respecti!ely.

Note: Te "ia!ram below as been pro%i"e" for illustrati%e purposes only. PS*ssoul" "elete te "ia!ram pro%i"e" an" supply information specific to te applicationre2uestin! appro%al.

$iti6en Web

0erver

#essaging

#iddleware

5irewallJ

Eplo%ee

E'ternal

,genc%,pplication

5irewall7

5inancial #anageent ,pplication $onceptual Design

D#K Internal Networ 9ardened Internal

NetworInternet

$redit $ard

-rocessing

0ervice

5irewallF

,pplication

0erver

Database

0erver

EDI

E'ternal

Business-artner

0ingle

&or :educed*

0ignHon

0ervice

5irewall F

Note: Narrati%e "escribin! te conceptual "esi!n of te application must be pro%i"e"imme"iately followin! te "ia!ram(s).

Solution Architecture Document Template Version: 1.0 age 1( of &'




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


19/35

. Gate : Preliminary System Desi!n

The reliminary System Design Section has been designed to capture only the most essentialinformation re7uired to obtain reliminary Design appro!al. hile the items listed are notintended to be an e4hausti!e list of the possible technologies that may be utili6ed in theimplementation of an application it does reflect some of the more common choices as /ell asimportant items that should be considered during the design phase.

.1 Preliminary System Ceclist

Disclaimer: ,ny tecnolo!ies liste" below a%e been pro%i"e" solely for con%enience8te information pro%i"e" is not inten"e" to be e5austi%e nor "oes it in"icate pro"ucten"orsement by TSG.

Preliminary System Ceclist &esponses 4 Select all tat apply

Developent ,pproach __ $oercial O!! 4he 0hel! &$O40 *

__ 5ree 2ibreL Open 0ource 0o!tware &52O00*

__ $oercial Open 0ource

__ $usto / Bespoe

;ote$ Customi1ations to C2* or


20/35

Preliminary System Ceclist &esponses 4 Select all tat apply

0%ste Integration 4echnologies

&Both for service provisioning and serviceconsumption*

__ .#2 __ Web 0ervices __ #essaging __ EDI __ $O:B,

__ IIO- __ ,daptors __ 0ecure 54-

__ -roprietar% ,-I via __________

__ Other &speci!%*1

Note$ K*+,- /*-- *+ &%0 Ser4ice Contract/ #'apter De"inition

&0'-&0 %e"er to #ppen'i # & *+-,0 + ,,*&*+-

*+/9&*+ :*&% 90('0& & &%0 (09;*0 //090, &%9>% &%0

(-&*+.

0ecurit% 4echnologies Secure Authentication:

e.g. *olution 'ntegrated authentication using login and passwordstored in the database

e.g. *olution 'ntegrated authentication using login and password viadatabase accounts stored in the RDB+*

e.g. *olution 'ntegrated authentication using certificate basedauthentication via accounts stored in the local directory service.

e.g. Providing local authentication to :rd parties via claims basedauthentication using 9*


21/35

. De%elopment ;uality Description

The De!elopment Guality Description section has been designed to capture ho/ 7ualityaspects such as portability maintainability e4tensibility supportability and re8usability shallbe reflected in the soft/are part of the proposed solution.

Portability

he ability for a solution to be migrated) installed on a different environment other then the original one, without the need ofany code changes.

Maintainability

"ase of e#tending the solution functionality, fi#ing of errors etc.

'5tensibility

he ability for the solution to be e#tended with ease and with minor modifications (future proof solution!.

Supportability

he ability for the solution to be more efficient in terms of product maintainability thus reducing operational costs (installation,configuration and monitoring! maintaining business continuity.

&e8usability

he ability to use modified or unmodified solution components (subroutines etc.! in other solutions.

Solution Architecture Document Template Version: 1.0 age 1C of &'






22/35

.7 Preliminary System Desi!n Description

ro!ide a diagram $or diagrams) /ith corresponding narrati!e that depicts an accurate and

detailed description of the preliminary design for the entire application. The design mustdocument ho/ each of the re7uirements specified in the conceptual design /ill be logicallyaccomplished. The preliminary design must align /ith the rinciples ractices andStandards that are published in the http:33ictpolicies.go!.mt andhttps:33///.mita.go!.mt3page.asp4EpageidF**B portals respecti!ely.

At this point properties such as scalability a!ailability and security posture should bereflected. 4ternal net/or5 connection speeds $for both the citi6en and employee) should bedocumented. The supporting application should perform at acceptable le!els /hen utili6inglo/est common access speeds. Specify any 5no/n hard/are and soft/are details $brandmodel !ersion etc) for clients ser!ers and other net/or5 infrastructure programminglanguages selected and deployment location $i.e. ser!er location /here code is deployed).#nterfaces must be identified.

Note The -ia+ram belo) ha" been pro,i-e- for illu"trati,e purpo"e" onl4* PSO" "houl--elete the -ia+ram pro,i-e- an- "uppl4 information "pecific to the application re8ue"tin+appro,al*

$iti6en

&?>>>

4ransactions

-er da%

0ervice

Broer

4ransactionKone5irewall

Eplo%eeDestop

&NCF>>*

E'ternal

,genc%

,pplication

Kone75irewall

2ine o! Business ,pplication 2ogical Design

4ransaction

Kone

&9ardened D#K*

Kone 7

&Internal Networ*

Kone F

&9ardened Internal

Networ*

Kone >/J

Internet

$oon -a%ent

0ervice

&$$ and ,$9*

$redit

$ard

,uthori6ation

EDI

E'ternal

Business

-artner

Identit%

,ccess

#anageent

0%ste

Kone F 5irewall

2oadBalancer

Web

0erver,ppl8

0erver

&$luster*

DB

0erver

irror*

+-N

+-NDedicated $ircuit

+-N +-N

+-N

:eote

,ccess

Eplo%ees

&NC?>*

002

5ield

Eplo%ees

&NCJ>>*

KoneF5irewall

W,N

+-N +-N

Note Narrati,e -e"cribin+ the preliminar4 -e"i+n of the application mu"t be pro,i-e-imme-iatel4 follo)in+ the -ia+ram("#*

Solution Architecture Document Template Version: 1.0 age *0 of &'




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


23/35

. System ,rcitecture ;uality Description

The Ser!ice Guality Description section has been designed to capture ho/ 7uality aspectssuch as erformance3Throughput Security #ntegrity 9eliability A!ailability Scalability"anageability Ser!iceability and 9eco!erability shall be reflected in the proposed solution.-ill in the applicable section hence reflecting ho/ the solution shall be deli!ered.

Performance/Trou!put

2esponse times1 how !ast the s%ste handles individual re;uests in ters o! user e'perience8

Throuhput1 how an% re;uests the s%ste can handle8

'oncurrenc!1 how an% users or threads wor siultaneousl%

-ist down the mechanism)s that the solution uses to achieve) support the above mentioned factors where applicable

Security

Authentication1 4he substantiation o! the identit% o! a person or entit% related to the s%ste in soe wa%8

Authoriation1 4he de!inition and en!orceent o! peritted capabilities !or a person or entit% whose identit% has beenestablished8

Au#it1 4he abilit% to provide !orensic data attesting that the s%ste was used in accordance with stated securit% policies8

Assurance1 4he abilit% to test and prove that the s%ste has the securit% attributes re;uired to uphold the statedsecurit% policies8

Asset)rotection1 4he protection o! in!oration assets !ro loss or unintended disclosure and resources !rounauthori6ed and unintended use8

A#ministration1 4he abilit% to add and change securit% policies add or change how policies are ipleented in thes%ste and add or change the persons or entities related to the s%ste8

-ist down the mechanism)s that the solution uses to achieve) support the above mentioned factors

+nte!rity

4he capabilit% !or an application to bring data or a !unction !ro one application progra together with that o! anotherapplication progra8


&eliability

4he abilit% !or a s%ste to be aware o! the hardware and so!tware coponents to deterine where and wh% !ailure is highand conse;uentl% is able to appl% actions in order to reduce !ailure8


,%ailability

he ability of the system to function without service interruption or depletion despite abnormal or malicious events.


Scalability

, propert% o! a solution or process which indicates its abilit% to either handle growing aounts o! wor &in ters o! wor load

Solution Architecture Document Template Version: 1.0 age *1 of &'






24/35

capacit% coputational power etc8* in a grace!ul anner or the abilit% and ease o! enhancing the solution to handle newre;uireents8


Mana!eability

4he building blocs o! anageabilit% can be viewed as

Deplo!a6le:0olution deplo%ent &oving or replication o! in!oration or binaries* aspects8

Dianosa6le:,bilit% !or 0olution to provide auditing !unctionalit% to enable eas% tracing and diagnosis o! errors/ issues.

Disaster,reco%era6le:4he abilit% !or the solution to recover !ro runHtie crashes considerations should also include datarecover% aspects8


Ser%iceability

4he ease and e'tent o! changes that can be a!!ected without interrupting the application and the environent conse;uentl%a!!ecting availabilit%8


&eco%erability

4he abilit% towards a !ast eas% and reliable recover% o! business data !ro virtuall% an% disruption or event8


Solution Architecture Document Template Version: 1.0 age ** of &'






25/35


26/35

Detail System Ceclist &esponses 4 Select all tat apply

Browser 0upport he solution must be compatible and support the browser)s identified inthe Destop *oftware and Configuration standard %+'C * 4447$744@!.

__ Other &speci!% product and versions*1

-resentat ion H $lient 0ide 2anguages __ 94#2 __ D94#2 __ .#2 __ .94#2

__ +B8NE4 __$P __ 5lash

__ Mava ,ppl40( __ Mava

__ M+# &speci!% details*1

__ Mava0cript __ +B0cript

__ $QQ

__ Other &speci!%*1

,pplication 0tate __ $ooies1

__ NonH-ersistent $ooies

__ -ersistent $ooies

__ 0ession Ids

__ 0tate 0tored in 9idden 5ields

__ Other &speci!%*1

Web 0erver 2ocation __ -ublic 5acing __ Internal 5acing

Web 0erver Operating 0%ste __ Windows __ 2inu' __ Uni' __ Other &speci!%*1

0peci!% +ersion1

Web 0erver 0o!tware __ ,pache __ #icroso!t __ 0un __ Oracle__ Other &speci!%*1

0peci!% Edition and +ersion1

Web 0erver H 9igh ,vailabilit% 2oad Balanced1 __ Yes __ No

__ Other &speci!%*1

Web 0erver H 0peci!ications :ollout $on!iguration1

Nuber o! 0ervers1 __ $-Us/0erver1 __ $-U 4%pe1 _________

$-U 0peed1 _____ ,ount o! :,#1 ____

-rocessor ,rchitecture1 __ R@ Bit __ F7 Bit

#a'iu $on!iguration1

Nuber o! 0ervers1 __ $-Us/0erver1 __ $-U 4%pe1 __________

$-U 0peed1 _____ ,ount o! :,#1 ____


27/35


-resentation 0erver 0ide 2anguages __ ,0-8NE4 __ +B8NE4 __$P

__ M0- __ 0ervlets __ Mava

__ M+# &speci!% details*1

__ 0erver 0ide Includes &00I*

__ $QQ

__ Other &speci!%*1

,pplication 0erver Operating 0%ste __ Windows __ 2inu' __ Uni' __ Other &speci!%*1

0peci!% +ersion1

,pplication 0erver 0o!tware __ #icroso!t __ IB# __ 0un __ Oracle __ BE, __ Other &speci!%*1

0peci!% Edition and +ersion1

,pplication 0erver 9igh ,vailabilit% :,ID 0upported1 __ Yes __ No

0,N 0upported1 __ Yes __ No

#irroring 0upported1 __ Yes __ No

$lustering 0upported1 __ Yes __ No

(rid/On Deand 0upported1 __ Yes __ No

__ Other &speci!%*1

,pplication 0erver H 0peci!ications :ollout $on!iguration1


$-U 0peed1 _____ ,ount o! :,#1 ____




$-U 0peed1 _____ ,ount o! :,#1 ____


28/35


Database 0erver 9igh ,vailabilit% :,ID 0upported1 __ Yes __ No

0,N 0upported1 __ Yes __ No

#irroring 0upported1 __ Yes __ No

$lustering 0upported1 __ Yes __ No

(rid/On Deand 0upported1 __ Yes __ No

___ Other &speci!%*1

Database 0erver H 0peci!ications :ollout $on!iguration1


$-U 0peed1 _____ ,ount o! :,#1 ____




$-U 0peed1 _____ ,ount o! :,#1 ____


29/35


30/35

Note: Narrati%e "escribin! te "etail "esi!n of te application must be pro%i"e"imme"iately followin! te "ia!ram(s).


31/35


32/35

=. Tecnical ,rcitecture Domains

lease pro!ide any significant architectural information $that has not been pre!iouslypro!ided) for this application. Areas of particular interest include use of ne/ technologiesle!eraging e4isting infrastructure use of ne/ or emerging technologies and any de!iations

from the Agency Architecture rinciples Standards or ?est ractices.

=.1 Networ Domain:

ISpecify any additional informationJ

=. ,pplication Domain:


=.7 Data Domain:


=. Systems +nte!ration Domain:


=.< Groupware Domain:


=.= Platform Domain:


=.> 'nterprise Mana!ement Domain:


=.? Security Domain:


Solution Architecture Document Template Version: 1.0 age &0 of &'






33/35

>. ,ppen"i5 , 4 Ser%ice Contract/ ,"apter Definition

Section 1 9 3unctional

1. ;onsumption #nformation

ow is this service consumedE

he services provides an *+P relay from the consumer to gov.mt domains and other domains registeredthrough 'CA;; domain registration services, including subdomains and have the appropriate +ail "#changerD;* +echanisms in place.

he transmission of data through the consumption of this service is not secured through the use of -*)**-certificates, therefore it is the responsibility of the consumer to encrypt data.

0ser authentication for each connection is not re=uired.

*ender domain must be valid and defined by +'A *+D.

Access control is configured through


34/35

Section 9 *ter terms

1. Transactional

ow does this adapter support transaction, provide for compensation, or does not provide transactional facility at

all

2. Service Level Terms and Conditions

he *ervice -evel Agreements (*-A! and other terms and conditions related to the consumption of this service

he adapter is monitored through +'A central monitoring services via *;+P. he uptime availability is availablethrough the +'A hosting services. "ach consumer should not send more than 64 mails per second whenmessages do not e#ceed 64 ilobytes each.

Consumers abusing the system will be disconnected without notice.

3. uality of Service

9hat are the =uality checs that were carried out during the design, development and deployment of this adapterE

his adapter was designed according to '"< specifications and best practices. 't is based on 'P protocols toensure scalability and reusability. he implementation is controlled by the +'A Change +anagement process.

4. !uditin" Information

9hat are the auditing mechanisms in place, if available at all, including the data elements that are recorded forauditing purposesE 'nclude the Data Protection measures that are in place according to %+'C policy and-egislation

5. Defined processes

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

Re=uests for consumption of this adapter are controlled by +'A *+D. A change re=uest is re=uired to open port78 from the Private Runtime "nvironment to the service as defined under interfaces.

Re=uests for access to the adapter are identified through the architecture blueprint to be presented according toArchitecture Blueprint re=uirements available at https$))www.mita.gov.mt)page.asp#EpageidH77I. Pro>ect+anager is responsible to trigger change management process.

Solution Architecture Document Template Version: 1.0 age &* of &'






35/35

Section 7 9 &esponsibilities

This section pro!ides information about the roles and persons responsible for the pro!ision ofthe ser!ice through this adapter.

9esponsible 9ole 2rganisationeam

Accountable 9ole 2rganisationeam

;onsultati!e 9ole 2rganisationeam

#nformati!e 9ole 2rganisationeam

Solution Architecture Document Template Version: 1.0 age && of &'


Documents

1 Tsg Tpl Solution Architecture Template v1.0