TÖÖVÕTULEPING nr 4-7/0024-1

Tarbijakaitse ja Tehnilise Järelevalve Amet, registrikood 70003218, asukoht Endla 10a, Tallinn

10122, mida esindab peadirektor Kristi Talving (edaspidi „Tellija“)

ja

AS Helmes, registrikood 10364097, asukoht Lõõtsa 6b, Tallinn11415, mida volikirja nr 747 alusel

esindab Kert Valamaa (edaspidi „Töövõtja“),

keda edaspidi nimetatakse üheskoos kui „Pooled“ ja eraldi kui „Pool“,

võttes arvesse, et:

- Tellija korraldas väikehanke „Tarbijakaitse ja Tehnilise Järelevalve Ameti protsessijuhtimise

ja otsustustoe lahenduse analüüs“;

- Tellija tunnistas hankemenetluses 06.02.2024 protokolliga nr 4-11/23/0113/0009 edukaks

Töövõtja pakkumuse,

sõlmisid käesoleva töövõtulepingu (edaspidi „Leping“) alljärgnevas:

1. Lepingu dokumendid

1.1. Lepingu dokumendid koosnevad käesolevast Lepingust, Lepingu lisadest ning Lepingu

võimalikest muudatustest, milles lepitakse kokku pärast Lepingu allkirjastamist.

1.2. Lepingu allkirjastamise hetkel on sellel järgnevad lisad:

1.2.1. Lisa 1 – Tellija 17.01.2024 pakkumuse kutse;

1.2.2. Lisa 2 – Töövõtja 30.01.2024 pakkumus.

2. Lepingu objekt

2.1. Lepinguga kohustub Töövõtja koostama Tellijale detailanalüüsi, mis vastab pakkumuse kutse

lisas 1 toodud tingimusele, ja esitama selle Tellija poolt määratud keskkonna kaudu (edaspidi

"Töö"). Tingimustele vastava detailanalüüsi koostamise eelduseks on pakkumuse kutse lisas

1 toodud tingimustele vastava eelanalüüsi koostamine. Töö täpne maht ja ulatus ning

projektiplaan on määratletud Lisas 2.

2.2. Töö alla kuuluvad kõik Lepingu täitmiseks vajalikud materjalid, toimingud ja tööde tegemine

või teenuste osutamine, mida ei ole eraldi nimetatud, kuid mis oma olemuselt kuuluvad Töö

hulka ning on vajalikud lepinguliste kohustuste nõuetekohaseks täitmiseks.

3. Töö läbiviimise tingimused

3.1. Tellija:

2

3.1.1. määrab keskkonna, mille kaudu Töövõtja peab analüüsi esitama, ja tagab Töövõtjale

ligipääsu keskkonnale hiljemalt 3 tööpäeva jooksul alates Lepingu jõustumisest;

3.1.2. esitab Töövõtjale Töö teostamiseks vajalikud andmed ja informatsiooni;

3.1.3. teavitab Töövõtjat viivitamatult kirjalikku taasesitamist võimaldavas vormis kõikidest

asjaoludest, mis võivad tingida Töös muudatuste tegemise;

3.1.4. võib vajadusel pöörduda kolmanda isiku poole sõltumatu eksperthinnangu saamiseks

Töö kvaliteedi kohta.

3.2. Töövõtja:

3.2.1. esitab Töö üldlevinud dokumendi formaadis punktis 4.1 sätestatud tähtajaks Tellija

kontaktisikule;

3.2.2. teostab Töö professionaalselt ja nõuetekohaselt vastavalt Lepingu tingimustele,

lähtudes Tellija poolt esitatud informatsioonist, juhistest ning lähteülesandest;

3.2.3. lubab Tellijal kontrollida Töö teostamise käiku ja esitab Tellija nõudmisel Töö

teostamise kohta teavet;

3.2.4. kasutab Töö teostamisel oma töömeetodeid ja -vahendeid;

3.2.5. teavitab Tellijat viivitamatult võimalikust viivitusest Töö teostamisel, samuti muudest

asjaoludest, mis võivad mõjutada või takistada Lepingus sätestatud kohustuste täitmist

või õiguste realiseerimist;

3.2.6. teostab Tellija poolt sätestatud tähtajaks Tellija poolt nõutud parandused või esitab uue

Töö, kui Töö või selle osa ei vasta Lepingule ning Tellija on esitanud vastavasisulised

pretensioonid vastavalt punktile 4.3.

4. Töö üleandmine ja vastuvõtmine

4.1. Töö Tellijale üleandmise tähtaeg on 22.04.2024.a. Töö antakse üle Töövõtja poolt

allkirjastatud üleandmise-vastuvõtmise aktiga.

4.2. Tellija vaatab Töövõtja poolt esitatud Töö üle 5 tööpäeva jooksul arvates Töö esitamisest

Tellijale. Kui Töö vastab käesoleva Lepingu tingimustele, võtab Tellija Töö vastu, allkirjastab

vastavasisulise üleandmise-vastuvõtmise akti ning teavitab sellest e-kirja teel Töövõtja

kontaktisikut. Juhul, kui Tellija ei ole esitanud Töövõtjale kirjalikke pretensioone 5 tööpäeva

jooksul arvates Töö Tellijale esitamise päevast, on Töövõtja õigustatud lugema Töö

vastuvõetuks.

4.3. Juhul, kui Tellijal on pretensioone Töö kvaliteedi või Lepingu tingimustele vastavuse osas,

teavitab ta sellest Töövõtjat e-kirja teel ning osutab konkreetsele puudusele Töös ja määrab

mõistliku tähtaja puuduse kõrvaldamiseks või uue, Lepingu tingimustele vastava Töö

esitamiseks. Pärast puuduste ja vigade likvideerimist koostatakse üleandmise-vastuvõtmise

akt Poolte vahel vastavalt punktile 4.2.

4.4. Poolte poolt allkirjastatud Töö üleandmise-vastuvõtmise akt on aluseks Töövõtjale arve

esitamiseks.

5. Tasu suurus, väljamaksmise tähtaeg ja kord

5.1. Tellija tasub Töövõtjale Lepingu tingimustele vastava Töö eest tasu summas 24 632,00 eurot,

millele lisandub käibemaks (edaspidi „Tasu“).

5.2. Tellija tasub Töö eest pärast selle vastuvõtmist hiljemalt 21 kalendripäeva jooksul Töövõtja

3

esitatud e-arve kättesaamisest arvates. Töövõtja esitab arve masintöödeldaval kujul vastavalt

kehtivale e-arve standardile. Arvele märgitakse Tellija dokumendiregistris registreeritud

Lepingu number ja Lepingus nimetatud Tellija kontaktisik.

5.3. Punktis 5.1. sätestatud tasu on ainus Töövõtja tasu käesoleva Lepingu täitmise eest. Tellija ei

aktsepteeri lisakulutusi, mille osas Pooled ei ole eelnevalt kirjalikult kokku leppinud.

6. Konfidentsiaalsus ja isikuandmete töötlemine

6.1. Pooled on kohustatud Lepingu kehtivuse ajal ning tähtajatult pärast Lepingu lõppemist mitte

avaldama üksteist puudutavat ega Lepingu täitmise käigus saadud konfidentsiaalset infot.

Konfidentsiaalse info all mõistavad Pooled teineteisele antud igasugust infot, sh ärisaladust,

intellektuaalset omandit, isikuandmeid, mis ei ole kolmandatele isikutele üldises korras

kättesaadav, samuti infot, mida nad on saanud kolmandatelt isikutelt, kui Pool teab või peaks

teadma, et info on konfidentsiaalne. Kahtluse korral eeldatakse informatsiooni

konfidentsiaalsust.

6.2. Pooled ei loe konfidentsiaalseks infot, mis on avalikustatud juba enne selle andmist teisele

Poolele või mis avalikustatakse Pooltest sõltumatult, välja arvatud juhul, kui Poolel on

võimalik avalikustamist ära hoida.

6.3. Töövõtja kohustub kasutama konfidentsiaalset informatsiooni üksnes Lepingu kehtivuse ajal.

Pool tohib konfidentsiaalse informatsiooniga tutvumist võimaldada ainult sellistele isikutele,

kellele konfidentsiaalse informatsiooni avaldamine on vajalik Lepingu täitmiseks ja kellega

on sõlmitud konfidentsiaalsusleping.

6.4. Pooled toimivad isikuandmete käsitlemisel vastavalt isikuandmete kaitse üldmäärusele ja

isikuandmete kaitse seadusele. Pooled loevad isikuandmeteks mistahes andmed tuvastatud

või tuvastatava füüsilise isiku kohta, sõltumata sellest, millisel kujul või millises vormis need

andmed on. Pooled kohustuvad kohaldama asjakohaseid infoturbe meetmeid, sh

isikuandmete kaitse üldmääruse artiklis 32 sätestatud isikuandmete turvalisuse tagamise

meetmeid, tagamaks konfidentsiaalse info kaitse. Vastavasisulise nõude saamisel teeb Pool

mõistliku aja jooksul teisele Poolele kättesaadavaks kogu teabe, mis on vajalik tõendamaks

asjakohaste tehniliste ja korralduslike meetmete rakendamist.

7. Intellektuaalne omand

7.1. Töövõtja poolt Töö teostamise käigus loodust tulenev intellektuaalne omand kuulub Tellijale.

Kui Töövõtja annab Tellijale üle materjalid, mis ei ole Töövõtja poolt loodud, tagab Töövõtja

selliste materjalide osas vajalikud intellektuaalomandi õigused mis võimaldavad Tellijal

Tööd kasutada.

7.2. Töövõtja loovutab Tellijale kõik Tööga seonduvad varalised õigused ning annab Tellijale

ainulitsentsi Töö teostamise käigus loodu kasutamiseks all-litsentsi andmise õigusega kogu

autoriõiguste kehtivuse ajaks, kasutusvajaduse ära langemiseni ning ilma territoriaalsete

piiranguteta.

7.3. Töövõtja kinnitab, et tal on õigus Tellijale varalised õigused üle anda ning temale teadaolevalt

ei rikuta ühegi kolmanda isiku õigusi. Juhul, kui kolmas isik esitab Tellijale autoriõigustega

seonduvaid nõudmisi, hüvitab Töövõtja Tellijale kõik sellistest nõudmistest tulenevad kahjud

ja kulud.

7.4. Tasu autoriõiguste eest sisaldub punktis 5.1 nimetatud tasus.

8. Värbamiskeeld

4

Kumbki Pool ei värba ega püüa värvata teise Poole Lepingu täitmisele kaasatud töötajaid

Lepingu kehtivuse ajal ja ühe (1) aasta jooksul pärast Lepingu lõppemist.

9. Vastutus

9.1. Lepingust tulenevate kohustuste täitmata jätmisega või mittenõuetekohase täitmisega teisele

Poolele tekitatud otsese varalise kahju hüvitab kahju tekitanud Pool teise Poole nõudel. Poolte

vastutus on piiratud punktis 5.1. sätestatud Tasuga.

9.2. Lepingust tulenevate rahaliste kohustuste täitmisega viivitamise korral on Poolel õigus nõuda

kohustust rikkunud Poolelt viivist iga viivitatud päeva eest tähtaegselt tasumata summast

0,15% päevas.

9.3. Juhul, kui Tellijast mitteolenevatel põhjustel ei esita Töövõtja Tööd tähtaegselt, on Tellijal

õigus nõuda Töövõtjalt leppetrahvi 0,5% Tasust iga viivitatud kalendripäeva eest.

9.4. Kui Lepingus ei ole sätestatud teisiti, on teiste mitterahaliste kohustuste rikkumise korral

teisel Poolel õigus nõuda leppetrahvi kuni 20% Tasust.

9.5. Kui Pool rikub Lepingu p-st 6 ja/või 7 tulenevat kohustust, on teisel Poolel õigus nõuda temalt

leppetrahvi 500 eurot iga rikkumise kohta.

9.6. Tellijal on õigus leppetrahvi summa tasaarvestada Töövõtjale maksmisele kuuluva tasuga.

9.7. Leppetrahvi nõudmine ei välista Tellija õigust kasutada teisi seadusega ettenähtud

õiguskaitsevahendeid. Lisaks leppetrahvi tasumisele on Tellijal õigus nõuda Töövõtjalt

Lepingu täitmist ja/või kahju hüvitamist osas, mida leppetrahv ei katnud. Leppetrahvi

maksmine ja kahju hüvitamine ei vabasta Töövõtjat oma lepinguliste kohustuste edasisest

täitmisest.

9.8. Leppetrahvinõue või teade leppetrahvinõude esitamise kavatsuse kohta tuleb esitada 2 nädala

jooksul kohustuse rikkumise avastamisest arvates. Leppetrahvid ja viivised tuleb tasuda 14

päeva jooksul arvates vastava nõude saamisest.

10. Poolte kontaktisikud ja teabe vahetamine

10.1. Tellija kontaktisik Lepinguga seotud küsimustes, kellel on muu hulgas õigus

kontrollida Töö täitmist ja võtta vastu Töö, on: Arthur Allas, telefon +372 6201757 e-post:

[email protected].

10.2. Töövõtja kontaktisik Lepinguga seotud küsimustes, kellel on muu hulgas õigus anda

üle Töö, on: Linda Sassian, telefon +372 56609729, e-post: [email protected].

10.3. Töökorralduslikes küsimustes juhinduvad Pooled muu hulgas Lisa 1 Lisa 1 punktis 5

(töökorraldus) sätestatust.

10.4. Informatiivsed teated võib edastada telefoni teel. Juhul, kui teate edastamisel on

õiguslikud tagajärjed, peab teade olema edastatud kirjalikult Lepingus nimetatud

postiaadressile või Poole esindaja poolt allkirjastatuna Lepingus nimetatud e-posti aadressile.

10.5. Lepingu Pool on kohustatud kätte saadud ning vastust eeldavale teatele vastama 3

tööpäeva jooksul selle saatmisest arvates, kui teates ei ole vastamiseks ette nähtud pikemat

tähtaega.

10.6. Poole teade loetakse teise Poole poolt:

10.6.1. samal päeval kätte saaduks, kui teade on saadetud elektroonilisel teel kontaktisiku e-

posti aadressile tööpäeval enne kella 16.00;

10.6.2. järgmisel tööpäeval, kui teade on saadetud elektroonilisel teel kontaktisiku e-posti

5

aadressile tööpäeval pärast kella 16.00.

11. Lepingu jõustumine, muutmine ja lõpetamine

11.1. Leping jõustub selle viimase Poole poolt allkirjastamise päeval ja kehtib kuni Poolte

poolt lepinguliste kohustuste nõuetekohase täitmiseni või Lepingu ennetähtaegse

lõpetamiseni.

11.2. Lepingut võib muuta üksnes Poolte kirjalikul kokkuleppel ja muudatused

vormistatakse Lepingu lisana. Muudatused jõustuvad pärast viimase Poole poolt

allkirjastamist või Poolte poolt muudatuses märgitud tähtajal. Lepingu muutmisel järgivad

Pooled riigihangete seaduse §-s 123 sätestatud tingimusi.

11.3. Poolte kontaktandmete muutumisest tuleb teist Poolt teavitada mõistliku aja jooksul.

Kontaktandmete muutmist ei loeta Lepingu muutmiseks punkti 11.2 mõistes.

11.4. Pooltel on õigus Leping erakorraliselt ilma etteteatamistähtajata üles öelda juhul, kui

teine Pool rikub oluliselt Lepingust tulenevaid kohustusi, muu hulgas juhul, kui:

11.4.1. Töövõtja ei ole Lepingu tingimustele mittevastava Töö esitamise korral Töö puudust

kõrvaldanud või esitanud uut, Lepingule vastavat Tööd punkti 4.3 kohaselt nimetatud

tähtaja jooksul;

11.4.2. Tellija on viivituses punkti 5.2 kohaselt esitatud arve maksmisega vähemalt 30

(kolmkümmend) kalendripäeva;

11.4.3. esineb riigihangete seaduse §-s 124 nimetatud alus.

12. Lõppsätted

12.1. Pooled ei tohi Lepingust tulenevaid õigusi ja kohustusi kolmandale isikule üle anda

ilma teise Poole eelneva kirjaliku nõusolekuta.

12.2. Lepingust tulenevad vaidlused lahendatakse läbirääkimiste teel. Kokkuleppe

mittesaavutamisel lahendatakse vaidlus Eesti Vabariigi õigusaktidega sätestatud korras.

12.3. Lepinguga reguleerimata küsimustes juhinduvad pooled Eesti Vabariigis kehtivatest

õigusaktidest.

12.4. Poolte esindajad kinnitavad, et neil on kõik õigused ja piisavad volitused sõlmida

Leping esindatava nimel kooskõlas õigusaktidega ja neile teadaolevalt ei esine ühtegi

takistust Lepinguga võetud ja selles sätestatud kohustuste täitmiseks.

12.5. Lepingu sisu on avalik teave.

Tellija Töövõtja

(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)

Kristi Talving Kert Valamaa

Peadirektor Partner

Lisa 1

Tehniline kirjeldus

Protsessijuhtimise ja otsustustoe lahenduse analüüs

Sisukord

1 Sissejuhatus ..................................................................................................................................... 2

2 Mõisted ja lühendid ......................................................................................................................... 2

3 Analüüs ............................................................................................................................................ 3

4 Tööde teostamise aeg ja eeldatav maksumus .................................................................................. 4

5 Töökorraldus ................................................................................................................................... 4

6 Pakkumuse esitamine ...................................................................................................................... 5

7 Täiendavad materjalid ..................................................................................................................... 5

7.1 TTJA standardiseeritud loataotluse protsess (Lisa 4) .................................................................. 5

7.2 Majandustegevusteate taotluse esitamise protsess (Lisa 5) ......................................................... 5

7.3 Kasutajagruppide ootused ja vajadused protsessijuhtimise lahenduse kasutamisele uuel e-

teenuste platvormil (visioon) ................................................................................................................... 6

7.4 Mittefunktsionaalsed ja tehnilised nõuded .................................................................................. 6

2

1 Sissejuhatus

Käesolev dokument kirjeldab protsessijuhtimise ja otsustoe lahenduste võrdlusanalüüsi

nõudeid ning avab projekti tagamaid.

Tarbijakaitse ja Tehnilise Järelevalve Amet (TTJA) osutab ca 85 erinevat teenust. Aastas on

üle 115 000 teenuste kasutuskorra. Teenused võib jaotada 5 kategooriasse:

 tegevuslubade jm lubade väljastamine;

 riiklik järelevalve;

 tururegulatsioon;

 tarbijavaidluste lahendamine;

 nõustamisteenus;

 muud teenused.

Teenuste osutamiseks kasutatakse põhiliselt 2 infosüsteemi – JVIS ja MTR. Mõlemad

infosüsteemid on umbes 15 aastat vanad, nende väljavahetamisega on juba alustatud.

Infosüsteemide väljavahetamise projekt võtab eelduslikult 4-5 aastat. Infosüsteemide

väljavahetamine on osa e-teenuste projektist, mille käigus uuendatakse teenuste pakkumist

tervikuna. Juba on uuendatud teenuste äriprotsessid (sh on loodud standardiseeritud protsessid),

uuendamisel on teenuste organisatsioon ja juhtimine. Käimas on e-teenuste platvormi esimeste

komponentide arendus, mille raames luuakse võimekus 10 majandustegevusteate esitamiseks1

uuel e-teenuste platvormil. Tegemist on standardiseeritud loaprotsessi (vt p 7.1) kõige lihtsama

protsessivooga, mis ei nõua taotluse menetlust (vt p 7.2).

Loodav e-teenuste platvorm põhineb mikroteenuste arhitektuuril. Üleminek uuele platvormile

on kavandatud järk-järgult, mis tähendab, et paralleelselt on lähiaastatel kasutuses nii vanad

infosüsteemid (JVIS, MTR) kui ka uus loodav platvorm. Mikroteenustele üleminekul muutub

infosüsteemi arhitektuur oluliselt keerukamaks - palju erinevaid omavahel suhtlevaid

komponente seniste monoliitsete rakenduste asemel. Uuele platvormile üleminekuga toimuvad

muutused ka platvormide tehnilises halduses, platvormi arendusprotsessis ja kasutajatoes. Uute

arenduste tarneid tehakse senisest tihemini ja komponentide põhiselt. Senine teenuste

arendamise ja tarnete protsess on olemasolevates rakendustes olnud keerukas, mistõttu on

muudatuste sisseviimine olnud ressursimahukas. Samuti on puudunud teenuseomanikel

võimalus teenuste osutamise mõõtmiseks ja töö efektiivsuse hindamiseks, mistõttu on

teenusprotsesside „pudelikaelade“ ja protsesside automatiseerimisvõimaluste tuvastamine

olnud raskendatud

2 Mõisted ja lühendid

JVIS Järelevalve Infosüsteem

MTR Majandustegevuse register

TTJA e-teenuste

platvorm

Terviklik mikroteenustele rajatud infosüsteem, mille abil tulevikus

osutatakse ja hallatakse kõiki TTJA poolt osutatavaid teenuseid

MKM Majandus- ja Kommunikatsiooniministeerium

MFN Mittefunktsionaalsed nõuded

1 Kokku 43 majandustegevusteadet

3

3 Analüüs

Käesoleva projekti eesmärk on analüüsida turul pakutatavate protsessijuhtimise ja otsustustoe

tarkvarade sobivust TTJA ärivajadustele ning koostada detailanalüüs sobivaima lahenduse

kasutusele võtmiseks TTJA e-teenuste platvormil. Detailanalüüsi alusel peab olema võimalik

tellida protsessijuhtimise ja otsustustoe lahenduse integreerimise arendus.

Analüüsi eesmärk on leida sobivaim ja optimaalseim protsessijuhtimise ja otsustustoe tarkvara

lahendus, mis täidaks TTJA ärivajadusi (vt p 7.3), oleks kasutajasõbralik ning sobiks uue

arendatava e-teenuste platvormiga. Analüüs koosneb kahest etapist, eelanalüüsist ja

detailanalüüsist. Lahendus peab võimaldama lisaks protsessi tehnilisele juhtimisele protsesse

analüüsida ja optimiseerida.

Eelanalüüsi käigus täpsustatakse funktsionaalsused ja vajadused lähtuvalt punktis 7.3

väljatoodule ning läbiviidud intervjuudele Tellijaga. Arvesse tuleb võtta, et projekti raames

väljapakutav lahendus sobiks uue e-teenuste platvormi loodud ja loodavate komponentidega

(Lisa 3). Arendusjärgus oleva TTJA e-teenuste platvormi arenduses on arvestatud

protsessijuhtimise tarkvara kasutusele võtmise valmidusega (p 7.4.1).

Lahenduste võrdlemisel tuleb analüüsida vähemalt järgnevaid aspekte:

- lahenduse sobivus TTJA ärivajaduste ja eesmärkidega (p 7.3);

- lahenduse kasutusmugavus (arendajad vs tavakasutaja), tugi ja koolitusvõimalused;

- lahenduse integratsiooni võimalused ja ühilduvus olemasoleva TTJA e-teenuste

platvormi tehnilise lahendusega (sh tuleb välja tuua erinevate alternatiivide kitsaskohad)

(Lisa 3);

- lahenduse funktsionaalsused ja võimalused protsesside loomisel, muutmisel,

kustutamisel, analüüsimisel, optimeerimisel ning otsustustoe pakkumisel;

- lahenduse skaleeritavus ja jõudlus arvestades teenuste mahu kasvuga;

- lahenduse paindlikkus arvestades, et teenuste üle toomine uuele e-teenuste platvormile

toimub järkjärgult;

- lahenduse kasutuselevõtmise prognoositav kulu (lahenduse hankimise kulu, lahenduse

kasutusele võtmisest tingitud võimalikku arendustööde kulu);

- lahenduse kasutuselevõtmise prognoositav Tellija ajakulu selle juurutamisel, sealhulgas

eelduslikud meeskonnarollid;

- lahenduse kasutuselevõtmisega kaasnevate riskide analüüs ja nende

maandamismeetmete kulu;

- lahenduse kasutamise prognoositavad püsikulud lähtudes tootjapoolsetest suunistest ja

väljapakutud lahenduse eripärast 5-aastase ajaperioodi jooksul arvates lahenduse

kasutuselevõtmisest, sh majutus-, litsentsi-, hooldus- ja tööjõukulud.

Analüüsida tuleb vähemalt kolme erinevat protsessijuhtimise ja otsustustoe tarkvara lahendust.

Töövõtja pakub välja analüüsitavad protsessijuhtimise ja otsustustoe lahendused, lõplik valik

lepitakse kokku koostöös Tellijaga.

Eelanalüüsi teostamise metoodika on Töövõtja vaba valik ja tuleb edastada pakkumuses.

Analüüsitavate lahenduste valikul tuleb arvestada, et lahenduse potentsiaalseteks kasutajateks

on nii IT-haridust omavad isikud (nt tooteomanik) kui ka kasutajad (äripool), kellel puudub

vastav spetsiifiline ettevalmistus (nt teenuseomanikud).

Lahenduste eelanalüüsi järgselt esitatakse tulemused visuaalselt (nt tabelina) vahearuandes, kus

on välja toodud täpsustatud ärivajadused, tehnilised nõuded ning eelanalüüsitud lahenduste

4

vastavus neile. Töövõtja esitab vahearuandes argumenteeritud ettepaneku sobivaima ja

optimaalseima lahenduse osas. Tellija töörühm valib vahearuandes eelanalüüsitud lahenduste

vahel kõige sobivaima lahenduse, millele Töövõtja koostab detailanalüüsi.

Detailanalüüsi põhjal peab olema võimalik Tellijal hankida lahenduse kasutusele võtmiseks

vajalikud arendustööd e-teenuste platvormil. Loodud on detailne arenduskava lahenduse

realiseerimiseks e-teenuste platvormil (pilootteenus: majandustegevusteate esitamine vt p 7.2),

koos hinnanguliste arendusmahtudega.

Detailanalüüs peab sisaldama lahenduse funktsionaalset spetsifikatsiooni, IT arhitektuuri

dokumenti, IT infrastruktuuri vajadusi, arendusvajaduste kirjeldusi lahenduse kasutusele

võtmiseks, liideste kirjeldusi, andmemudeleid, üldiste

kasutuslugude/protsesside/stsenaariumite kirjeldusi (sh protsessijooniseid) jms. Detailanalüüsis

tuleb lisaks välja tuua hinnanguline jätkuarenduste kava (sh tellija poolsed tegevused,

hinnangulised arendusmahud), mis on vajalikud protsesside juhtimise tarkvara kasutusele

võtmiseks kogu loateenuse protsessil (p 7.1). Detailanalüüsis tuleb anda 5- aastase ajaperioodi

püsikulude prognoos lähtudes tootjapoolsetest suunistest ja väljapakutud lahenduse eripärast

(majutus-, litsentsi-, hooldus- ja tööjõukulud). Detailanalüüs peab arvestama arhitektuurile

seatud kehtivaid nõudeid (p 7.4.1).

Analüüsis tuleb arvestada p 7.4 väljatoodud mittefunktsionaalsete nõuetega.

4 Tööde teostamise aeg ja eeldatav maksumus

Hanke tulemusena sõlmitakse hankeleping. Pakkumuse maksumus esitatakse eurodes

käibemaksuta. Pakkumuses esitatud hind on lõplik ning Tellija ei aktsepteeri täiendavaid

lisakulutusi. Projekti eeldatav maksumus on 25 000 eurot (km-ta).

Tööde läbiviimise ajakava:

- Projekti algus on hiljemalt 7 päeva peale lepingu jõustumist.

- Eelanalüüs tuleb Tellijale üle anda hiljemalt 3 nädalat pärast lepingu jõustumist.

- Lepingu punktis 2.1. määratletud Töö (sh detailanalüüs) peab olema Tellijale

üleantud hiljemalt 2 kuud pärast lepingu jõustumist.

5 Töökorraldus

Projekti eesmärkide ja ülesannete elluviimiseks moodustatakse töörühm, mille komplekteerib

Tellija.

Avakoosolekul lepitakse kokku nende kohtumiste ja täiendavate töögruppide ja/või töötubade

töökorraldus. Avakoosoleku kutse saadab välja Tellija.

Töövõtja ülesanded on töö tulemite dokumenteerimine (sh eel- ja detailanalüüs), koosolekute

memode koostamine.

Analüüsiga seotud dokumentatsioon on korrektselt vormistatud nii õigekeele, terminoloogia,

viitamise kui tehnilise vormistuse mõttes.

Dokumentatsiooni haldamiseks ja jagamiseks luuakse ligipääsud Tellija poolt määratud

keskkonda. Dokumentide hoidmise struktuur, selle täiendused ja muudatused lepitakse kokku

poolte vahel projekti avakohtumisel.

5

Tööde tulemina valmivad nõuded, tehniline spetsifikatsioon, juhend, raportid, arenduskavade

kirjeldused, töö käigus kokkulepitud vaheetappide tulemusena valminud protokollid, memod,

aruanded ja muu oluline dokumentatsioon antakse üle vastavalt Tellija antud juhistele.

6 Pakkumuse esitamine

Pakkuja esitab pakkumuses:

Tööde kirjelduse koos ajakavaga, kuidas ülesandeid planeeritakse lahendada ja nõutud

tulemused saavutada. Projektiplaani kavandis tuleb välja tuua tegevused, tulem(id), ajakava,

vaheetapid, orienteeruv ajakulu, kuidas on hallatud riske, tagatud tulemuste kvaliteet ja ootused

Tellijale. Pakkumisega tuleb esitada vähemalt kolme võrreldava lahenduse nimekiri.

Võrreldavad tooted peavad vastama ärivajadustele (p 7.3). Täiendavalt tuleb pakkumuses

põhjendada, miks on otsustatud võrrelda konkreetseid lahendusi.

7 Täiendavad materjalid

7.1 TTJA standardiseeritud loataotluse protsess (Lisa 4)

7.2 Majandustegevusteate taotluse esitamise protsess (Lisa 5)

6

7.3 Kasutajagruppide ootused ja vajadused protsessijuhtimise lahenduse kasutamisele uuel

e-teenuste platvormil (visioon) 2

Allpool kirjeldatud ootused ja vajadused ei ole lõplikud ning täpsustakse detailanalüüsi käigus.

1) Teenuse kvaliteedimõõdikute monitooring ja analüüs (teenuseomanik)

a) Kasutaja peab saama vaadata osutatud teenuste koguarvu ja keskmist

menetlusaega.

b) Kasutaja peab saama määrata ajavahemiku, et näha sellel ajavahemikul osutatud

teenuste arvu ja keskmist menetlusaega.

c) Kasutaja peab saama filtreerida osutatud teenuste arvu ja keskmist menetlusaega

vastavalt teenuse liigile.

d) Kasutaja peab saama vaadata menetluse aega.

e) Kasutaja pea saama vaadata igas menetlusetapis kulunud aega.

f) Kasutaja peab saama vaadata jooksvate menetluste järge.

g) Kasutajal peal olema võimalik määrata protsessi sammudele etalonväärtuseid.

h) Kasutaja peab saama teenuse põhisel vaadata keskmist menetlusetappide

läbimiste arvu.

i) Kasutaja peab saama vaadata statistikat menetlusetappide läbimiste koguarvu

kohta.

j) Kasutaja peab saama juhtumipõhiselt vaadata menetlusetappide läbimiste arvu.

k) Kasutaja peab saama luua raporteid.

2) Teenuse intsidentide haldus (kasutajatugi, tooteomanik)

a) Kasutaja peab saama vaadata, millises protsessi etapis antud protsessi instants on

selleks, et saada informatsiooni võimalikust veakohast.

b) Kasutaja peab saama hallata protsessi instantsi parameetreid selleks, et teha

veaotsingut ning lahendada võimalik viga.

c) Kasutajal peab olema ülevaade jooksvatest protsessidest ja nende konkreetsetest

seisudest, et saada informatsiooni süsteemi hetkeolukorrast.

d) Kasutaja peab saama protsessi samme tagasi võtta selleks, et lahendada võimalik

viga.

3) Teenuste seadistamist (tooteomanik, teenuseomanik)

a) Lahendus peab võimaldama protsesside versioneerimist.

b) Lahendus peab võimaldama ärireeglite kirjeldamist ja haldamist (DMN)

(loomine, muutmine, kustutamine),

c) Lahendus peab võimaldama BPMN kujul protsesside kirjeldamist ja haldamist

selleks, et võimaldada süsteemist arusaamist üldlevinud notatsiooni abil.

4) Lahendus peab sisaldama otsustusmootorit.

a) Lahendus peab võimaldama otsustustoe protsesse luua, hallata ning käivitada.

7.4 Mittefunktsionaalsed ja tehnilised nõuded

7.4.1 TTJA e-teenuste platvormi arhitektuur ja tehnilised nõuded sisalduvad Lisas 3 –

arhitektuur.

7.4.2 KeMITi mittefunktsionaalsed nõuded:

2 Põhinevad 2021. aastal teostatud „TTJA teenuste kasutusmugavuse ja ärianalüüsil“ ning 2022. aastal toimunud

teenusomanike töötubadel.

7

https://www.kemit.ee/sites/kemit/files/2023-

04/KeMIT%20Mittefunktsionaalsed%20n%C3%B5uded%2025.04.2023.pdf

Lisa 2 – Hankelepingu projekt

TÖÖVÕTULEPING nr ..

Tarbijakaitse ja Tehnilise Järelevalve Amet, registrikood 70003218, asukoht Endla 10a, Tallinn

10122, mida esindab peadirektor Kristi Talving (edaspidi „Tellija“)

ja

…, registrikood …, asukoht …, mida põhikirja/volikirja alusel esindab juhatuse liige/… … (edaspidi

„Töövõtja“),

keda edaspidi nimetatakse üheskoos kui „Pooled“ ja eraldi kui „Pool“,

võttes arvesse, et:

- Tellija korraldas väikehanke „Tarbijakaitse ja Tehnilise Järelevalve Ameti protsessijuhtimise ja

otsustustoe lahenduse analüüs“;

- Tellija tunnistas hankemenetluses pp.kk.aaaa protokolliga nr … edukaks Töövõtja pakkumuse,

sõlmisid käesoleva töövõtulepingu (edaspidi „Leping“) alljärgnevas:

1. Lepingu dokumendid

1.1. Lepingu dokumendid koosnevad käesolevast Lepingust, Lepingu lisadest ning Lepingu

võimalikest muudatustest, milles lepitakse kokku pärast Lepingu allkirjastamist.

1.2. Lepingu allkirjastamise hetkel on sellel järgnevad lisad:

1.2.1. Lisa 1 – Tellija pp.kk.aaaa pakkumuse kutse;

1.2.2. Lisa 2 – Töövõtja pp.kk.aaaa pakkumus.

2. Lepingu objekt

2.1. Lepinguga kohustub Töövõtja koostama Tellijale analüüsi, mis vastab pakkumuse kutse lisas 1

toodud tingimusele, ja esitama selle Tellija poolt määratud keskkonna kaudu (edaspidi "Töö").

Töö maht ja ulatus on määratletud Lisas 2.

2.2. Töö alla kuuluvad kõik Lepingu täitmiseks vajalikud materjalid, toimingud ja tööde tegemine

või teenuste osutamine, mida ei ole eraldi nimetatud, kuid mis oma olemuselt kuuluvad Töö

hulka ning on vajalikud lepinguliste kohustuste nõuetekohaseks täitmiseks.

3. Töö läbiviimise tingimused

3.1. Tellija:

3.1.1. määrab keskkonna, mille kaudu Töövõtja peab analüüsi esitama, ja tagab Töövõtjale

ligipääsu keskkonnale hiljemalt 3 tööpäeva jooksul alates Lepingu jõustumisest;

3.1.2. esitab Töövõtjale Töö teostamiseks vajalikud andmed ja informatsiooni;

3.1.3. teavitab Töövõtjat viivitamatult kirjalikku taasesitamist võimaldavas vormis kõikidest

asjaoludest, mis võivad tingida Töös muudatuste tegemise;

3.1.4. võib vajadusel pöörduda kolmanda isiku poole sõltumatu eksperthinnangu saamiseks Töö

kvaliteedi kohta.

3.2. Töövõtja:

3.2.1. esitab Töö üldlevinud dokumendi formaadis punktis 4.1 sätestatud tähtajaks Tellija

kontaktisikule;

3.2.2. teostab Töö professionaalselt ja nõuetekohaselt vastavalt Lepingu tingimustele, lähtudes

Tellija poolt esitatud informatsioonist, juhistest ning lähteülesandest;

3.2.3. lubab Tellijal kontrollida Töö teostamise käiku ja esitab Tellija nõudmisel Töö teostamise

kohta teavet;

3.2.4. kasutab Töö teostamisel oma töömeetodeid ja -vahendeid;

Lisa 2 – Hankelepingu projekt

3.2.5. teavitab Tellijat viivitamatult võimalikust viivitusest Töö teostamisel, samuti muudest

asjaoludest, mis võivad mõjutada või takistada Lepingus sätestatud kohustuste täitmist või

õiguste realiseerimist;

3.2.6. teostab Tellija poolt sätestatud tähtajaks Tellija poolt nõutud parandused või esitab uue

Töö, kui Töö või selle osa ei vasta Lepingule ning Tellija on esitanud vastavasisulised

pretensioonid vastavalt punktile 4.3.

4. Töö üleandmine ja vastuvõtmine

4.1. Töö Tellijale üleandmise tähtaeg on pp.kk.2024.a. Töö antakse üle Töövõtja poolt allkirjastatud

üleandmise-vastuvõtmise aktiga.

4.2. Tellija vaatab Töövõtja poolt esitatud Töö üle 5 tööpäeva jooksul arvates Töö esitamisest

Tellijale. Kui Töö vastab käesoleva Lepingu tingimustele, võtab Tellija Töö vastu, allkirjastab

vastavasisulise üleandmise-vastuvõtmise akti ning teavitab sellest e-kirja teel Töövõtja

kontaktisikut. Juhul, kui Tellija ei ole esitanud Töövõtjale kirjalikke pretensioone 5 tööpäeva

jooksul arvates Töö Tellijale esitamise päevast, on Töövõtja õigustatud lugema Töö

vastuvõetuks.

4.3. Juhul, kui Tellijal on pretensioone Töö kvaliteedi või Lepingu tingimustele vastavuse osas,

teavitab ta sellest Töövõtjat e-kirja teel ning osutab konkreetsele puudusele Töös ja määrab

mõistliku tähtaja puuduse kõrvaldamiseks või uue, Lepingu tingimustele vastava Töö

esitamiseks. Pärast puuduste ja vigade likvideerimist koostatakse üleandmise-vastuvõtmise akt

Poolte vahel vastavalt punktile 4.2.

4.4. Poolte poolt allkirjastatud Töö üleandmise-vastuvõtmise akt on aluseks Töövõtjale arve

esitamiseks.

5. Tasu suurus, väljamaksmise tähtaeg ja kord

5.1. Tellija tasub Töövõtjale Lepingu tingimustele vastava Töö eest tasu summas … eurot, millele

lisandub käibemaks (edaspidi „Tasu“).

5.2. Tellija tasub Töö eest pärast selle vastuvõtmist hiljemalt 21 kalendripäeva jooksul Töövõtja

esitatud e-arve kättesaamisest arvates. Töövõtja esitab arve masintöödeldaval kujul vastavalt

kehtivale e-arve standardile. Arvele märgitakse Tellija dokumendiregistris registreeritud

Lepingu number ja Lepingus nimetatud Tellija kontaktisik.

5.3. Punktis 5.1. sätestatud tasu on ainus Töövõtja tasu käesoleva Lepingu täitmise eest. Tellija ei

aktsepteeri lisakulutusi, mille osas Pooled ei ole eelnevalt kirjalikult kokku leppinud.

6. Konfidentsiaalsus ja isikuandmete töötlemine

6.1. Pooled on kohustatud Lepingu kehtivuse ajal ning tähtajatult pärast Lepingu lõppemist mitte

avaldama üksteist puudutavat ega Lepingu täitmise käigus saadud konfidentsiaalset infot.

Konfidentsiaalse info all mõistavad Pooled teineteisele antud igasugust infot, sh ärisaladust,

intellektuaalset omandit, isikuandmeid, mis ei ole kolmandatele isikutele üldises korras

kättesaadav, samuti infot, mida nad on saanud kolmandatelt isikutelt, kui Pool teab või peaks

teadma, et info on konfidentsiaalne. Kahtluse korral eeldatakse informatsiooni

konfidentsiaalsust.

6.2. Pooled ei loe konfidentsiaalseks infot, mis on avalikustatud juba enne selle andmist teisele

Poolele või mis avalikustatakse Pooltest sõltumatult, välja arvatud juhul, kui Poolel on võimalik

avalikustamist ära hoida.

6.3. Töövõtja kohustub kasutama konfidentsiaalset informatsiooni üksnes Lepingu kehtivuse ajal.

Pool tohib konfidentsiaalse informatsiooniga tutvumist võimaldada ainult sellistele isikutele,

kellele konfidentsiaalse informatsiooni avaldamine on vajalik Lepingu täitmiseks ja kellega on

sõlmitud konfidentsiaalsusleping.

Lisa 2 – Hankelepingu projekt

6.4. Pooled toimivad isikuandmete käsitlemisel vastavalt isikuandmete kaitse üldmäärusele ja

isikuandmete kaitse seadusele. Pooled loevad isikuandmeteks mistahes andmed tuvastatud või

tuvastatava füüsilise isiku kohta, sõltumata sellest, millisel kujul või millises vormis need

andmed on. Pooled kohustuvad kohaldama asjakohaseid infoturbe meetmeid, sh isikuandmete

kaitse üldmääruse artiklis 32 sätestatud isikuandmete turvalisuse tagamise meetmeid, tagamaks

konfidentsiaalse info kaitse. Vastavasisulise nõude saamisel teeb Pool mõistliku aja jooksul

teisele Poolele kättesaadavaks kogu teabe, mis on vajalik tõendamaks asjakohaste tehniliste ja

korralduslike meetmete rakendamist.

7. Intellektuaalne omand

7.1. Töövõtja poolt Töö teostamise käigus loodust tulenev intellektuaalne omand kuulub Tellijale.

Kui Töövõtja annab Tellijale üle materjalid, mis ei ole Töövõtja poolt loodud, tagab Töövõtja

selliste materjalide osas vajalikud intellektuaalomandi õigused mis võimaldavad Tellijal Tööd

kasutada.

7.2. Töövõtja loovutab Tellijale kõik Tööga seonduvad varalised õigused ning annab Tellijale

ainulitsentsi Töö teostamise käigus loodu kasutamiseks all-litsentsi andmise õigusega kogu

autoriõiguste kehtivuse ajaks, kasutusvajaduse ära langemiseni ning ilma territoriaalsete

piiranguteta.

7.3. Töövõtja kinnitab, et tal on õigus Tellijale varalised õigused üle anda ning temale teadaolevalt ei

rikuta ühegi kolmanda isiku õigusi. Juhul, kui kolmas isik esitab Tellijale autoriõigustega

seonduvaid nõudmisi, hüvitab Töövõtja Tellijale kõik sellistest nõudmistest tulenevad kahjud ja

kulud.

7.4. Tasu autoriõiguste eest sisaldub punktis 5.1 nimetatud tasus.

8. Vastutus

8.1. Lepingust tulenevate kohustuste täitmata jätmisega või mittenõuetekohase täitmisega teisele

Poolele tekitatud otsese varalise kahju hüvitab kahju tekitanud Pool teise Poole nõudel.

8.2. Lepingust tulenevate rahaliste kohustuste täitmisega viivitamise korral on Poolel õigus nõuda

kohustust rikkunud Poolelt viivist iga viivitatud päeva eest tähtaegselt tasumata summast 0,15%

päevas.

8.3. Juhul, kui Tellijast mitteolenevatel põhjustel ei esita Töövõtja Tööd tähtaegselt, on Tellijal õigus

nõuda Töövõtjalt leppetrahvi 0,5% Tasust iga viivitatud kalendripäeva eest.

8.4. Kui Lepingus ei ole sätestatud teisiti, on teiste mitterahaliste kohustuste rikkumise korral teisel

Poolel õigus nõuda leppetrahvi kuni 20% Tasust.

8.5. Kui Pool rikub Lepingu p-st 5 ja/või 6 tulenevat kohustust, on teisel Poolel õigus nõuda temalt

leppetrahvi 500 eurot iga rikkumise kohta.

8.6. Tellijal on õigus leppetrahvi summa tasaarvestada Töövõtjale maksmisele kuuluva tasuga.

8.7. Leppetrahvi nõudmine ei välista Tellija õigust kasutada teisi seadusega ettenähtud

õiguskaitsevahendeid. Lisaks leppetrahvi tasumisele on Tellijal õigus nõuda Töövõtjalt Lepingu

täitmist ja/või kahju hüvitamist osas, mida leppetrahv ei katnud. Leppetrahvi maksmine ja kahju

hüvitamine ei vabasta Töövõtjat oma lepinguliste kohustuste edasisest täitmisest.

8.8. Leppetrahvinõue või teade leppetrahvinõude esitamise kavatsuse kohta tuleb esitada 2 nädala

jooksul kohustuse rikkumise avastamisest arvates. Leppetrahvid ja viivised tuleb tasuda 14 päeva

jooksul arvates vastava nõude saamisest.

9. Poolte kontaktisikud ja teabe vahetamine

9.1. Tellija kontaktisik Lepinguga seotud küsimustes, kellel on muu hulgas õigus kontrollida Töö

täitmist ja võtta vastu Töö, on: Arthur Allas, telefon +372 620 1757 e-post: [email protected].

9.2. Töövõtja kontaktisik Lepinguga seotud küsimustes, kellel on muu hulgas õigus anda üle Töö,

on: …, telefon …, e-post: ….

Lisa 2 – Hankelepingu projekt

9.3. Töökorralduslikes küsimustes juhinduvad Pooled muu hulgas Lisa 1 Lisa 1 punktis 5 sätestatust.

9.4. Informatiivsed teated võib edastada telefoni teel. Juhul, kui teate edastamisel on õiguslikud

tagajärjed, peab teade olema edastatud kirjalikult Lepingus nimetatud postiaadressile või Poole

esindaja poolt allkirjastatuna Lepingus nimetatud e-posti aadressile.

9.5. Lepingu Pool on kohustatud kätte saadud ning vastust eeldavale teatele vastama 3 tööpäeva

jooksul selle saatmisest arvates, kui teates ei ole vastamiseks ette nähtud pikemat tähtaega.

9.6. Poole teade loetakse teise Poole poolt:

9.6.1. samal päeval kätte saaduks, kui teade on saadetud elektroonilisel teel kontaktisiku e-posti

aadressile tööpäeval enne kella 16.00;

9.6.2. järgmisel tööpäeval, kui teade on saadetud elektroonilisel teel kontaktisiku e-posti

aadressile tööpäeval pärast kella 16.00.

10. Lepingu jõustumine, muutmine ja lõpetamine

10.1. Leping jõustub selle viimase Poole poolt allkirjastamise päeval ja kehtib kuni Poolte poolt

lepinguliste kohustuste nõuetekohase täitmiseni või Lepingu ennetähtaegse lõpetamiseni.

10.2. Lepingut võib muuta üksnes Poolte kirjalikul kokkuleppel ja muudatused vormistatakse

Lepingu lisana. Muudatused jõustuvad pärast viimase Poole poolt allkirjastamist või Poolte poolt

muudatuses märgitud tähtajal. Lepingu muutmisel järgivad Pooled riigihangete seaduse §-s 123

sätestatud tingimusi.

10.3. Poolte kontaktandmete muutumisest tuleb teist Poolt teavitada mõistliku aja jooksul.

Kontaktandmete muutmist ei loeta Lepingu muutmiseks punkti 10.2 mõistes.

10.4. Pooltel on õigus Leping erakorraliselt ilma etteteatamistähtajata üles öelda juhul, kui teine

Pool rikub oluliselt Lepingust tulenevaid kohustusi, muu hulgas juhul, kui:

10.4.1. Töövõtja ei ole Lepingu tingimustele mittevastava Töö esitamise korral Töö puudust

kõrvaldanud või esitanud uut, Lepingule vastavat Tööd punkti 4.3 kohaselt nimetatud tähtaja

jooksul;

10.4.2. Tellija on viivituses punkti 5.2 kohaselt esitatud arve maksmisega vähemalt 30

(kolmkümmend) kalendripäeva;

10.4.3. esineb riigihangete seaduse §-s 124 nimetatud alus.

11. Lõppsätted

11.1. Pooled ei tohi Lepingust tulenevaid õigusi ja kohustusi kolmandale isikule üle anda ilma

teise Poole eelneva kirjaliku nõusolekuta.

11.2. Lepingust tulenevad vaidlused lahendatakse läbirääkimiste teel. Kokkuleppe

mittesaavutamisel lahendatakse vaidlus Eesti Vabariigi õigusaktidega sätestatud korras.

11.3. Lepinguga reguleerimata küsimustes juhinduvad pooled Eesti Vabariigis kehtivatest

õigusaktidest.

11.4. Poolte esindajad kinnitavad, et neil on kõik õigused ja piisavad volitused sõlmida Leping

esindatava nimel kooskõlas õigusaktidega ja neile teadaolevalt ei esine ühtegi takistust

Lepinguga võetud ja selles sätestatud kohustuste täitmiseks.

11.5. Lepingu sisu on avalik teave.

Tellija Töövõtja

(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)

Kristi Talving ….

peadirektor …

Lisa 2 – Hankelepingu projekt

Arhitektuuri visioon Originaalfailid: TTJA arhitektuur v1.zip

1. Sisukord

1. Sisukord 2. Äriarhitektuur 3. Andmearhitektuur

3.1. Põhiandmed 3.2. Protsessi andmeid 3.3. Binaarandmed 3.4. Suurandmed 3.5. Avaandmed 3.6. Andmemudelid ja andmete hoidmise tehnoloogiad

3.6.1. Relatsiooniline andmemudel 3.6.2. Dokumentandmemudel 3.6.3. Blokkandmehoidla

3.7. Andmemigratsioon ja sünkronisatsioon 3.8. Andmeolemite keskne haldus

4. Tarkvara arhitektuur mikroteenustel 4.1. Kontseptuaalne arhitektuur 4.2. Tugimoodulid

4.2.1. Identiteedi ja pääsuhalduse moodulid 4.2.2. Autentimise moodul 4.2.3. Isikute moodul 4.2.4. Administratiivmoodul 4.2.5. Maksete moodul 4.2.6. Failide moodul 4.2.7. Tehnilise konfiguratsiooni moodul 4.2.8. Allkirja moodul 4.2.9. Teavitus- ja kommunikatsioonimoodul 4.2.10. Ärilogi moodul 4.2.11. Avaandmete lüüs 4.2.12. Kaardimoodul

4.3. Andmevahetusmoodulid 4.3.1. Süsteemi komponentide andmevahetuse põhimõtted 4.3.2. Süsteemi väliste osadepoolte andmevahetuse põhimõtted 4.3.3. Programmliideste pääsulüüs 4.3.4. X-tee moodul 4.3.5. Asünkroonsete sõnumite vahetuskiht

4.4. Andmemoodulid 4.4.1. Andmebaasimootor 4.4.2. Põhiandmete pääsulüüs 4.4.3. Pinumälu (cache) 4.4.4. Andmete indekseerimine 4.4.5. Pseudonüümimise moodul 4.4.6. Andmete sünkronisaator moodul

4.5. Äriprotsessi moodulid 4.5.1. Protsessimootori kasutamise põhimõtted 4.5.2. Võimalikud eraldiseisvad ärimoodulid

4.6. Kasutajaliidese moodulid 4.6.1. Mikrokasutajaliidesed 4.6.2. Kasutajaliidese disainimustrid ja -vahendid 4.6.3. Andmevahetus tagarakendustega

4.7. Olemasolevad tarkvarad 5. Majutusarhitektuur

5.1. Kontseptuaalne evitus 5.2. Majutustööriistad

5.2.1. Pilveplatvorm Kubernetes 5.2.2. Pideva paigaldamise tarkvara 5.2.3. Monitooring 5.2.4. Tehnilised logid

5.3. PostgreSQL andmebaasi kõrgkäideldatav evitus 5.4. Infrastrutkuuri esialgne indikatiivne vajadus

6. Andmeturve põhimõtted ja ülevaade 6.1. Andmeturbe põhimõtted 6.2. Andmekogude tsoneerimine

7. Tarkvara arendamise ja testimise metoodikad ja praktikad 7.1. Tarkvara arendamise ja projektijuhtimise metoodika 7.2. Testimise metoodikad ja praktikad

7.2.1. Funktsionaalne testimine 7.2.2. Mittefunktsionaalne testimine

8. Koodi- ja konfiguratsiooni haldus, tehiste ehitamine, tarne 8.1. Lähtekoodi haldus, tarne ja CI/CD

8.1.1. Lähtekoodi majutamine 8.1.2. Lähtekoodi tarne haldus 8.1.3. Lähtekoodi ehitamine ja sõltuvuste haldus 8.1.4. Pidev integreerimine ja pidev tarne (CI/CD)

8.2. Konfiguratsioonide haldus 8.2.1. Rakenduste ja keskkondade seaded 8.2.2. Äriprotsessi seaded

9. Süsteemi majutus- ja administreerimise põhimõtted 9.1. DevOps 9.2. GitOps 9.3. Majutus Riigipilves

10. Kasutatud kirjandus

2. Äriarhitektuur Tarbijakaitse ja Tehnilise Järelevalve Amet (edaspidi TTJA) on loodud 2019 aastal mitme riigiasutuse ja ameti liitmisel ja tegutseb põhimääruse alusel.1 2

Nimetatud konsolideerimise tulemusena sündis ühendametkond, millel on üsna lai tegevuste spekter, ja seetõttu tähtis roll Eesti riigis ja ühiskonnas.

Ameti põhitegevuseks on ohutusjärelevalve, tururegulatsioon ning seadusest tulenevate kohustuste täitmise kontrollimine järgmistes valdkondades:

elektrooniline side, sagedushaldus ja meediateenused; raudteetransport ja EL struktuurivahendite rakendamine; eripädevusnõuetega tööde ning seadmete ja toodete ohutus; ehitised, taristu ja energiatõhusus; tarbijaõigused.

TTJA pakub oma ülesannete täitmisel järgmisi teenuseid:

tegevus- ja kasutusõiguse andmine (tööstus-, ehitus- ja raudteeohutus, elektrooniline ja raadioside); riiklik järelevalve (tööstusohutus, ehitusvaldkond, energiatõhusus, raudteeohutus, elektrooniline side ja meediateenused, raadiosageduste kasutamine, tarbijaõigused); nõustamistegevus; tarbijavaidluste lahendamine.

TTJA asutamisega võttis organisatsioon üle erinevatelt asutustel ka nende asutuste protsessid ja protsesse teotavad infotehnoloogilised lahendused sh. infosüsteemid ja andmebaasid.

TTJA strateegiliste eesmärkide elluviimiseks on tarvilik reformida nii olemasolevaid äriprotsesse, kui ka neid toetavaid infosüsteeme. Planeerida süsteemi3

muudatused vastavalt käesoleva aja parimetele infotehnoloogilistele praktikatele ja kaaluda ka tulevikus potentsiaalsete innovaatiliste lahenduste kaasamist infotehnoloogia arendamisel, testimisel, juurutamisel ja haldamisel. Olemasolevad süsteemid on nii moraalselt, kui ka tehniliselt vananenud ja nende edasiarendamine on osutunud ebamõistlikuks.

3. Andmearhitektuur Käeolevas peatükis tutvustame süsteemi andmearhitektuuri, klassifitseerime andmed ja tutvustame põhilisi süsteemis kasutatavaid andmesalvestustehnoloogiaid. Samuti nende rakendamist süsteemi osade disainimisel.

Andmed üldiselt jagunevad mitmesugusteks. Käesolevas dokumendis klassifitseerime andmed loogilisteks gruppideks ja käsitleme igat gruppi eraldiseisvalt, näiteks protsessi andmed, binaarandmed, suurandmed, avaandmed ja äriprotsesside põhiandmed.

3.1. Põhiandmed

Põhiandmete all mõistame andmeid, mis on eelkõige kirjeldatud õigusaktides näiteks seadus, andmekogu põhimäärus, ministri määrus, korraldus vms. Nende andmete seas on äriprotsessi käigus kogutud ja tekkinud põhilised andmed näiteks avaldused, otsused, õigused jne. Nendel andmetel on määratud andmeturbest lähtuv ISKE turvaklass , kogumise alus ja säilitamise tähtaeg. Põhiandmetega toimub äriprotsess (menetlus), mille käigus olemasolevaid4

andmeid muudetakse või tekib juurde uusi põhiandmeid. Põhiandmed omavad ka väljaspool IT süsteemi tähtsust ja tähendust. Põhiandmeid jagatakse ühiskonnale välja avaandmetena ja teiste riigi äriprotsessidele üle riikliku andmevahetusplatvormi.

TTJA vaates on baasandmed kirjeldatud alljärgnevates õigusaktides:

MTR

Majandustegevuse seadustiku üldosa seadus (lühend – MSÜS)5

JvIS

Seadme ohutuse seadus https://www.riigiteataja.ee/akt/123032015004?leiaKehtiv Tarbijakaitse ja Tehnilise Järelevalve Ameti järelevalve infosüsteemi põhimäärus https://www.riigiteataja.ee/akt/124032020010

NBA

Elektroonilise side seadus (ESS) https://www.riigiteataja.ee/akt/112122018033?leiaKehtiv Majandus- ja kommunikatsiooniministri määrus "Nõuded numbri liikuvuse tagamiseks sideettevõtja vahetamisel" https://www.riigiteataja.ee/akt /126022019012?leiaKehtiv

Majandus- ja kommunikatsiooniministri määrus "Numbri broneerimise tingimused" https://www.riigiteataja.ee/akt/103072015016?leiaKehtiv Directive 2002/22/EC of the European Parliament and of the Council on universal service and users' rights relating to electronic communications networks and services (Universal Service Directive) https://ec.europa.eu/digital-single-market/en/news/directive-universal-service-and-users- rights-relating-electronic-communications-networks-and Directive 2002/58/EC concerning the processing of personal data and the protection of privacy in the electronic communications sector and Regulation (EC) https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=celex%3A32002L0058 No 2006/2004 on cooperation between national authorities responsible for the enforcement of consumer protection laws (Text with EEA relevance). https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32004R2006

SASS

Elektroonilise side seadus (ESS) https://www.riigiteataja.ee/akt/112122018033?leiaKehtiv Majandus- ja kommunikatsiooniministri määrus "Raadiosageduste kasutamise tingimused ja tehnilised nõuded sagedusloast vabastatud raadioseadmetele" https://www.riigiteataja.ee/akt/126022019014?leiaKehtiv Majandus- ja kommunikatsiooniministri määrus "Tehnilised nõuded sagedusloa alusel kasutatavatele raadioseadmetele" https://www.riigiteataja. ee/akt/117062014008?leiaKehtiv Komisjoni otsus teabe kättesaadavuse ühtlustamise kohta seoses raadiospektri kasutamisega ühenduses 2007/344/EÜ https://eur-lex.europa.eu /legal-content/ET/TXT/?uri=CELEX:32007D0344

GIS

Elektroonilise side seadus (ESS) § 1002 https://www.riigiteataja.ee/akt/112122018033?leiaKehtiv Sideteenuse katvuse, kasutuse ja võimaluste kaardistuse infosüsteemi põhimääruse kinnitamine https://adr.mkm.ee/? id=72B0329323B341B2C2258081002C4D39

Antud nimekiri pole ammendav ega lõplik.

3.2. Protsessi andmeid

Protsessiandmete all mõistame andmeid, mis tekivad või muutuvad äriprotsessi (menetluse) läbimise käigus, kuid kirjeldavad ainult konkreetset äriprotsessi ja selle omadusi. Nendeks võib lugeda protsessi andmeühikuks millal protsess käivitus (algatati menetlus), milline asutuse töötaja või osapool konkreetselt antud protsessis osaleb, mis toiminguid protsessis tehakse, äriprotsesi staatus jne. Protsessi tehniline kirjeldus (masin-töödeldav algoritm või meta-keelne teisend) võivad ise ka olla protsessi andmed (BPMN notatsioonis kirjeldus). Protsessi andmete alla võib lugeda ka äriprotsessi seadistusi ja muutujate väärtuseid.

3.3. Binaarandmed

Binaarandmete all mõistame andmeid, mille esitluskuju on binaarne, üldjuhul ei ole binaarandmed mõistlikul või üldlevinud viisil masin loetavad ja - töödeldavad. Neil ei ole primaarset teksitilist esitluskuju. Eelkõige on binaarsel kujul failid näiteks pildifailid, PDF dokumendid, heli ja videoklipid jne.

3.4. Suurandmed

Suurandmeteks nimetatakse selliseid andmekogumeid, mis on nii suured ja keerukad, et nende töötlemiseks tuleb kasutada uusi tehnoloogiaid . Neid6

andmeid iseloomustavad üldjuhul suur maht, suur juurdetekkimise kiirus ja suur variatiivsus .7

TTJA-s tegeleb suurandmetega antud dokumendi loomise ajal projekt "TTJA Andmeait".

Käesolevas dokumendis kirjeldatud mikroteenustel arhitektuuri elluviimisel muutub oluliselt süsteemi andmemudel sh. võivad kasutsuele tulla uued tehnoloogiad ja andmesalvestuse vahendid. Andmeaida arendamisel peab silmas pidama uute andmemudelite ja andmeformaatide temaatikat ja vajadusel tegema koostööd uue platvormi välja töötajatega.

3.5. Avaandmed

Avalikud avaandmed (valitsusandmed) tähendavad andmeid, mille on kogunud, tootnud või mille eest on tasunud avaliku sektori asutused ning mis on muudetud vabalt kättesaadavaks ja mis tahes otstarbel taaskasutatavaks. Kasutamistingimused on täpsemalt määratletud litsentsis.8

Avaandmetega seonduv on juhendmaterjalina avaldatud Avaandmete loomise ja avaldamise juhendis ja Eesti avaandmed on koondatud Eesti9

avaandmete portaali .10

Käesolevas dokumendis kirjeldatud süsteemis luuakse ja jagatakse avaandmeid. Avaandmete loomise ja avaldamise tehniline lahendus on kirjeldatud peatükis . 4.2.12

3.6. Andmemudelid ja andmete hoidmise tehnoloogiad

Käesolevas alapeatükis kirjeldame lähemalt võimalikku andmete säilitamise ja töötlemise põhimõtteid ja lahendusi. Põhiliselt käsitleme kolme olulisemat andmete säilitamise viisi a) relatsiooniline, b) dokument orienteeritud ja c) blokkhoidla. Eelkõige keskendume füüsilisele andmemudelile, mitte loogilisele. Loogiline andmemudel oma üleüldiselt joondub rohkem relatsioonilise andmemudeliga.

3.6.1. Relatsiooniline andmemudel

Relatsiooniline andmebaas põhineb relatsioonilisel mudelil ehk baasi loogiline struktuur koosneb relatsioonide kogumist. Relatsioonilise andmemudeli kontseptsiooni esitas 1970. aastal Edgar Frank Codd. Sünonüümselt võib relatsiooni nimetada ka tabeliks, mille struktuur koosneb olemi atribuutidest ja andmekogumitest, teisisõnu veergudest ja ridadest, kus iga veerg saab hoida ainult ühte tüüpi andmeid . Traditsioonilistes andmebaasi mootorites on11

relatsiooniline andmemudel implementeeritud tabelite, mis koosnevad veergudest ja ridade gruppidest, mis on loogiliselt omavahel seotud viidete ja viitetabelite (vahetabelite) kaudu. Füüsilise adnmemudeli saamiseks tuleb loogilist andmemudelit normaliseerida. 

3.6.2. Dokumentandmemudel

Viimase dekaadi jooksul on infotehnoloogias kogunud populaarsust termin NoSQL , mis on saanud sünonüümiks dokument orienteeritud12

andmehoidlatele. Dokument andmemudeli üheks omaduseks võib olla, et otseselt ei eksisteeri objekti iseloomustavat tabelit, vaid eksisteerib mingis tekstilises andmevormingus näiteks JSON andmekomplekt, mida nimetatakse „dokumendiks”. Dokument orienteeritud andmebaasi süsteemid on näiteks Apache CouchDB, MongoDB. Nimetud andmebaasimootorite kohta kehtiks küll termin NoSQL, kuna nendes kasutamiseks ei kasutata SQL süntaksit. Küll aga on dokument orienteeritud andmete säilitamine võimalik ka klassikaliste relatsiooniliste andmebaasimootoritega nagu näiteks PostgreSQL. Sealt edasi on võimalik ehitada ka hübriidlahendusi, kus vastavalt vajadusele on võimalik mõlemat andmemudelit kombineerida.

Kuna JSON andmeformaat on andmevorming IT-maailmas, siis käsitletakse dokument andmebaasides praktiliselt ainult JSON andmekomplektidede facto hoiustamist. Muus vormingus dokument andmemudelid on marginaalsed. Näiteks on ajalooliselt XML andmete andmebaasis hoidmine olnud võimalik pea samal viisil, kui JSON andmete, kuid sellel on olnud sisulised ja fundamentaalsed puudused, mistõttu ei ole selle kasutamine juurdunud. JSON andmeformaadis andmekomplekti näidis on kujutatud joonisel 1 ja JSON Schema samale andmekomplektile on kujutatud joonisel 2.13

Oluline on ka asjaolu, et dokument-andmemudel ei asenda relatsioonilist andmemudelit kõigis stsenaariumites ja dokument andmemudel ei sobi kõigi ärijuhtude tarbeks andmete säilitamiseks. Kuna relatsiooniline andmemudel on eksisteerinud pikka aega on andmebaasi mootorid optimeeritud töötama relatsiooniliste andmetega. On spetsiifilised funktsioonid ja operatsioonid mille saavutamine dokument orienteeritud andmebaasis võrreldes relatsioonilisega on oluliselt keerulisemad.

Dokument orienteeritud andmemudelit on võimalik defineerida läbi meta-skeemi. JSON andmevormingu puhul on võimalik defineerida andmekomplekti kasutades JSON Schema funktsionaalsust. Käesoleval hetkel ei toeta PostgreSQL JSON Schema kasutamist otse andmebaasi funktsionaalsel tasemel, seega tuleb andmekomplekt kirjeldada andmebaasi väliselt või hüübriidmudeliga. PostgreSQL JSON Schema toega on olemas mitmeid tarkvaraarenduse teeke, mis selle probleemi näiteks Java keeles ära lahendavad.

Joonis 1. Näidis JSON andmekomplekt

Joonis 2. näidis JSON skeem

Antud näite JSON skeemist järeldub, et andmekomplektis on kolm kohustuslikku atribuuti eesnimi, perekonnanimi ja vanus. Samuti on kirjeldatud nende lihttüüp ja määratud JSON Schema lisaatribuut „ ”, mida saab kasutada, et kirjeldada atribuuti. JSON Schema-s on lisaks veel mitmeid atribuute, midatitle ära kasutada JSON objekti kirjeldamiseks. JSON andmekomplekti on võimalik vastu skeemi valideerida ja kontrollida.

3.6.3. Blokkandmehoidla

Andmeid, millised on kirjeldatud peatükis tuleb hoida blokkandmete hoidlas. Käesoleval ajal on kujunenud üleüldiseks standardiks kasutada3.3 blokkandmete hoidlateks tehnilisi lahendusi, mis pakuvad andmete salvestamist ja ligipääsu andmetele kasutades Amazon S3 blokihoidmise lähenemisega. S3 on üldtunnustatud protokoll binaarandmetele ligipääsuks. Riigipilv pakub blokkandmehoidla teenust StorageVault . BlokihoidlaPilw.io 14

puuduseks on asjaolu, et selles, ei saa hoida binaarandmete-failide kohta käivat metainfot näiteks faili tüüp, laiend, omanik, märksõnad, viited indeksitele jne. Selleks tuleb luua süsteemi komponent, mis haldab binaarandmete metainfot.

3.7. Andmemigratsioon ja sünkronisatsioon

Uuele platvormile üleminekul peab samal ajal hoidma töös ka vana süsteemi. Kuna vanas süsteemis on ka palju andmeid tuleb neid hakata järk järgult üle viima uuel platvormil arendatud süsteemi.

Detailanalüüsi käigus tuleb täpselt spetsifitseerida, millised andmed, millal ja mis viisil üle kolitakse ja milliseid andmeid sünkroniseeritakse.

Andmemigratsioon on ühekordne tegevus, mida tehakse vanast süsteemist uude süsteemi. Seda tehakse, kas spetsiaalselt loodava mikroteenusega, SQL migratsiooni skriptidega või mõne valmistarkvaraga. Tuleb hinnata eraldi, millisesse andmehoidu lahendusse andmed üle kantakse ja mis migratsiooni strateegiat tuleks antud olukorras kasutada. Relatsiooniliselt andemudelilt dokument orienteeritud andmemudelile üle viimisel on soovituslik kasutada mikroteenust, kus tegevuste käigus toimub ka andmete valideerimine ja vajadusel andmete parandamine.

Andmete sünkroniseerimisel on sama andmestik olemas mõlemas süsteemis, nii vanas kui ka uues. Sünkroniseerimiseks kasutatakse eraldi arendatud mikroteenust, mille ülesanne on hoida uue ja vana süsteemi andmebaasid samade andmetega, kui selline vajadus on.

Andmete sünkroniseerimisega tegelev võimalik mikroteenus on kirjeldatud peatükis .4.4.6

Andmete migreerimiseks on mõstlik kasutada vabavaralisi tööriistu näiteks , replicatsiooni puhul nt .pgloader pglogical

3.8. Andmeolemite keskne haldus

Suures organisatsioonis, kus käitatakse palju erinevaid äriprotsesse on kasutusel paralleelselt palju erinevaid andmeolemeid. Andmeolemid läbivad kõiki kihte, kuni tehnilise kihini välja. Andmeolemite üle tuleks pidada arvestust ja neid keskelt hallata. Keskselt hallatud andmeolemid tuleks kirjeldada kasutades JSON Schema standardit ja hoiustada GIT koodihoidlas. Mõned andmeolemite keskselt haldamise eelised ja põhimõtted on alljärgnevad:

Annab hea ülevaate süsteemi andmeolemitest; On võimalik kasutada dokumentatsioonina; Mainsloetaval kujul andmeolemitest ja nende sostest on võimalik genereerida diagramme; Masin loetaval kujul hoiustatud andmeolemeid on võimalik konverteerida tarkvara lähtekoodi klassideks. (Java puhul -deks);POJO Masin loetaval kujul hoiustatud andmeolemitest on võimalik genereerida testandmeid ja näidisandmeid; Kõigil osapooltel on võimalik pääseda ligi andmeolemite kirjeldustele.

Lisaks andmeolemite kesksele haldusele tuleks koos andmeolemitega keskselt hallata ka testandmeid ja näidisandmeid.

Joonisel 3 on kujutatud andmeolemite ja testandmete keskset haldust.

Joonis 3. Andmeolemite ja testandmete keskne haldus

4. Tarkvara arhitektuur mikroteenustel Selles peatükis kirjeldame süsteemi kontseptuaalne arhitektuuri ja selgitame detailsemalt arhitektuuri osi. Süsteemi kirjeldamiseks oleme kasutanud sõna „moodul”, mis on antud dokumendi raames mikroteenuse sünonüüm. Kogu süsteemi oleme klassifitseerinud viieks moodulite blokiks 1) Tugimoodulid, 2) Andmevahetusmoodulid, 3) Andmemoodulid, 4) Äriprotsessi moodulid ja 5) Kasutajaliideste moodulid. Igas alampeatükis on detailsemalt selgitatud vastava domeeni moodulite omadused ja sisu. Samuti on eraldi alampeatükis selgitatud moodulite vahelised andmevahetus põhimõtted.

4.1. Kontseptuaalne arhitektuur

Käesolevas alapeatükis pakume välja loodava süsteemi kontseptuaalse arhitektuuri, esitledes süsteemi komponente ja mooduleid, nende funktsioone ja käitamise asjaolusid.

Mikroteenuste arhitektuuri põhimõtted on alljärgnevad:

Mikroteenus on ühte või mitut sarnast funktsiooni realiseeriv eraldi seisvalt paigaldatav autonoomne süsteemi komponent; Mikroteenus võib realiseerida ühte funktsiooni või mitut sarnaselt grupeeritud funktsiooni; Mikroteenus on teistest komponentidest otseselt mitte sõltuv iseseisev komponent; Mikroteenus on majutuskohas iseseisvalt skaleeritav ja hallatav komponent; Mikroteenuste arhitektuur võimaldab pakendatud funktsionaalsust sõltumatult, eraldiseisvalt arendada ja testida; Mikroteenusteks võib jagada funktsioone ka administratiivsete või projektorganisatoorsete asjaolude järgi; Mikroteenusel on enda andmebaas või pole seda üldse; Mikroteenus pöördub teise mikroteenuste (andmete) poole läbi programmliidese (API) või keskse andmesiini; Mikroteenuste arhitektuur käsitleb üldjuhul tagarakenduste ja kommunikatsioonirakenduste skoopi, mitte aga kasutajaliideste skoopi.

Eelnev nimekiri pole lõplik ega ammendav.

Süsteemi kontseptuaalne arhitektuur on kirjeldatud joonisel 4. Joonise paremaks loetavuseks on süsteemi osad tähistatud erinevate värvidega alljärgnevalt

a) roheline – uued komponendid, mis tuleb arendada (või taaskasutada mingit tarkvara), b) kollane – süsteemid, mis eksisteerivad, c) oranž – autentimise ja autoriseerimise moodulid, d) sinine – andmebaas või andmehoidlad, e) punane – olemasolevad taakvarad ( ),legacy software f) roosa – muu väline osapool või tugisüsteem, g) hall – kommunikatsiooni moodulid, mis tuleb luua.

Joonisel toodud seostes on päringu teenindaja märgitud joone ja mummuga või kriipsjoone ja noolega, päringu tarbija (võib olla päringu algataja) on märgitud poolkaarega, teenuse pakkuja on märgitud mummuga. Seose peale võib olla märgitud andmevahetuse protokoll. Eraldi äärisega on tähistatud valdkonnad, millistel on täpsemad joonised käesoleva dokumendi alapeatükkides. Noolega on tähistatud andmet sõltuvuse suund või päringute liikumise suund.

Joonis 4. Süsteemi kontseptuaalne arhitektuur

Rõhutame, et näidatud arhitektuur on kontseptuaalne. Arenduste ja süsteemi loomise käigus võib tekkida vajadusi luua juurde mooduleid, milliseid pole võimalik käesolevas dokumendis ette näha. Küll aga tuleb arvestada, et moodulite arvu suurenemisel suureneb ka halduskeerukus ja süsteemi evitusega senduvad väljakutsed. Mida rohkem on mikroteenuseid seda keerulisem on evitus.

4.2. Tugimoodulid

Käesolevas peatükis käitleme detailsemalt tugimooduleid, nende funktsioone ja tehnilisi lahendusi.

4.2.1. Identiteedi ja pääsuhalduse moodulid

Kasutajate, rollide, õiguste ja nende omavahelise halduse, pääsu saladuste jne hoidmiseks tuleb luua eraldi moodul Kõik süsteemis kasutusel olevad õigused ja rollid asuvad käesolevas moodulis. Kõik süsteemi tehtavad päringud autoriseeritakse vastu seda moodulit, et kontrollida pääsuõiguse kehtivust. Moodul genereerib, haldab ja väljastab JWT võtmeid .15

Käesoleva mooduli tarkvaraliseks lahenduseks tuleks kasutada Keycloak tarkvara, mis on üks levinum avatud lähtekoodiga identiteedi ja pääsuhalduse16

valmistoode.

Joonisel 5 on kujutatud täpsemalt identiteedi ja pääsuhalduse korraldus mikroteenuste arhitektuuris.

Joonis 5. Kasutajate, õiguste, ligipääsude haldus mikroteenuste arhitektuuris

Kasutaja interaktsiooni esimene samm toimub kasutajaliideses, kust suunatakse kasutaja riiklikusse autentimisportaali. Autentimisportaal edastab tuvastatud identiteedi andmed kasutajate halduse, ligipääsu moodulisse, kus seotakse need kasutajaga. Kasutaja puudumisel luuakse kasutaja ja seotakse vaikimisi rollidega isikute mooduli andmete põhjal. Tuvastatud kasutaja Internetisirvikule edastatakse JWT võti , mis sisaldab informatsiooni17

kasutaja identiteedi kohta. Edaspidistele päringutele süsteemi suunas paneb sirvik JWT võtme kaasa mistõttu, saab pääsulüüs, või mis tahes mikroteenus kontrollide päringu vastu võtmisel JWT võtme autentsust ja päringu tegija õigust päringut sooritada. Kasutajate halduse moodulisse saab lisada kasutaja juurde andmeid, mille abil on võimalik seostada kasutajat-isikut mingi juriidilise kehaga või mingite andmetega. Kuna JWT võtit saab kaasa anda ka mikroteenustele, siis on võimalik seoste informatsiooni põhjal andmetele ligipääsu kontrollida.

4.2.2. Autentimise moodul

Autentimise mooduli ülesanne on korraldada kasutajate autentimist ja vahendada kasutajale sessiooni tunnust koos vajaliku meta-informatsiooniga.

Autentimise mooduliks kasutame RIA TARA lahendust, mis on iseseisvalt hallatav valmis tarkvaratoode. Moodul sisaldab tuge mitmesugustele autentimislahendustele ja on integreeritav Keycloak pääsuhalduse tarkvaraga.

4.2.3. Isikute moodul

Isikumooduli ülesanne on hallata ja säilitada informatsiooni sh. ajalugu süsteemis eksisteerivate juriidiliste- ja füüsiliste isikute kohta. Isikute moodul suhtleb süsteemi väliste osapooltega, mis sisaldavad isikute infot. Näiteks Äriregister – juriidiliste isikute andmed, Rahvastikuregister – füüsiliste isikute andmed. Andmevahetus nimetatud registritega käib üle X-tee vastava mooduli vahendusel. Isikute moodul on isikuandmete „tõe allikas” süsteemi jaoks.

Isikute moodul peaks olema Java keeles arendatud tarkvara või TEHIK TEIS projekti arendatud kloon või võrdväärne.persons-service18

4.2.4. Administratiivmoodul

Administratiivmooduli ülesanne on koondada süsteemi administratiivsed funktsioonid. Nendeks on näiteks:

Klassifikaatorite haldus; Äriliste parameetrite haldus; Tõlgete haldus; Abitekstide haldus; Infotekstid; Aadresside, asukohtade haldus (ADS) – käesolevas dokumendis toodud välja ka eraldi moodulina.

Äriliste parameetrite halduse ja teenustele pakkumise funktsionaalsuse saaks delegeerida ka tehnilise konfiguratsiooni moodulile.

Administratiivmoodul moodul peaks olema Java keeles arendatud tarkvara.

Kuna administratiivmooduli käsitletud andmed on üldjuhul üsna staatilised, siis tuleks need võimalikult palju hoida rakenduse või minumälu baasis. Nii on võimalik tagada päringutele kiired vastamised.

4.2.5. Maksete moodul

Maksete mooduli ülesanne on koondada maksete teostamise ja riigilõivude kogumise funktsioonid. Nendeks on näiteks:

Riigilõivude informatsiooni hankimine; Riigilõivude hinnakirja haldamine; Viitenumbrite genereerimine; Makseplatvormi pakkumine; Liidestumine maksevahendajaga, pangalinkidega;

Maksete moodul peaks olema Java keeles arendatud tarkvara. Näidiseks saab võtta näiteks TEHIK TeIS projekti käigus arendatud tarkvaramooduli payments-service .19

4.2.6. Failide moodul

Failide mooduli eesmärk on vahendada teistele moodulitele binaarandmeid. Failide salvestamist oleme käsitlenud peatükis . Failide mooduli4.2.6 andmestikus salvestatakse ka failide metainfo.

Allkirja moodul peaks olema Java keeles arendatud tarkvara või TEHIK TeIS projekti arendatud kloon.signing-service20

4.2.7. Tehnilise konfiguratsiooni moodul

Tehnilise konfiguratsiooni moodul on vajalik süsteemi teiste moodulite tehnilise rakendusseadete üle programmliidese pakkumiseks. Süsteemis kasutatavad Spring Boot tarkvaraarenduse raamistikul arendatavad rakendused vajavad spetsiifilisel kujul tehnilist konfiguratsiooni. Üks võimalus nende konfigureerimiseks on konfiguratsiooniserver-klient andmevahetus. Mikroteenuse rakenduse käivitamisel küsib see tehnilise konfiguratsiooni moodulilt endale seaded.

Tehniliselt tuleb kasutada Java keeles arendatud ja tarkvaraarenduspaketti, mille andmehoidlaks onSpring Cloud Config22 Spring Cloud Config Client23

näiteks GIT (Gitlab repositoorium piiratud ligipääsuga). Lisaks GIT-ile on toetatud ka mitmed teised andmehoidlad.

Mikroteenused, millised vajavad tehnilist seadistamist kasutavad teeki ja on seadistatud laadima sisse endale seadedSpring Cloud Config Client konfiguratsioonimoodulist vastavalt spetsifikatsioonis määratud profiilile.

Joonisel 6 on sealhulgas kujutatud tehnilise konfiguratsiooni mooduli asukoht ja suhtlus osapooltega.

Joonis 6. Tehnilise konfiguratsiooni haldus

Tehnilise konfiguratsiooni mooduli võib ka ära jätta, kui on täielikult rakendatud käesolevas dokumendis peatükis  kirjeldatud GitOps põhimõtted ja9.2 kasutusel süsteemi majutuse halduse operaator tarkvara Argo CD või samaväärne. Sellisel juhul on tehniline konfiguratsioon siiski hallatud GIT-is, kui see antakse rakendusele ette läbi Kubernetes platvormi võimaluste. Pole vaja jagada tehnilisi seadistusi rakendustele üle REST teenuse.

4.2.8. Allkirja moodul

Allkirja mooduli ülesanne on signeerida andmeid ja kontrollida signatuuride korrektsust. Allkirja moodul suhtleb väliste osapoolte ja süsteemidega, mis osalevad signeerimises või signatuuri kontrollimises. Näiteks vajadusel SiVa ja SiGa teenus, riistvara turvamoodul (HSM), ajatempliteenus jne. Kasutades PKC11 protokolli saab moodul suhelda ka riistsvaralise turvamooduliga HSM (Harware Secure Module).

Allkirja moodul peaks olema Java keeles arendatud tarkvara või TEHIK TeIS projekti arendatud kloon.signing-service24

4.2.9. Teavitus- ja kommunikatsioonimoodul

Teavituste moodul koondab endas funktsioone, millised on seotud kommunikatsiooniga inimeste ja institutsioonide vahel viisil, mis infovahetus pole masintöödeldavas formaadis.

Tekstimallide haldus; PDF faili mallide haldus; Lõpptekstide loomine mallidest ja muutujate väärtustest; PDF failide loomine; E-kirjade loomine ja välja saatmine; SMS-ide välja saatmine; Osapooltega vahetatud kiirsõnumite haldus.

Loetelu pole lõplik. Konkreetne funktsioonide nimekiri kinnitatakse detailanalüüsiga.

Teavitus- ja kommunikatsioonimoodul moodul peab olema Java keeles arendatud tarkvara, mille puhul võib aluseks võtta näiteks TEHIK TeIS projekti arendatud kloon.messages-service25

4.2.10. Ärilogi moodul

Mitmel juhul on vaja, et ärilistest tegevustest jääks maha tegevuste logi, mille tähtsaim eesmärk on, et oleks hiljem võimalik üheselt aru saada mis toimus, mis andmeid vaadata või mis andmeid muudeti. Põhimõtteliselt on võimalik ärilogi või ka auditlogi hallata kahel viisil 1) Logikanded salvestatakse andmebaasi, 2) sarnaselt nagu tehniline logi, kuid eraldiseisva andmekomplektiga. Tehnilise logi käitlemine on kirjeldatud peatükis . Äri- ja auditlogi5.2.4 tuleks tehnilisest logist logi pinus ( ) füüsiliselt eraldada, et neid oleks võimalik eraldiseisvalt töödelda ja erineva tähtajaga säilitada.logstack

Logide salvestamisel andmebaasi tuleks jälgida, et logide andmebaasi tabelid oleks mõistlikult partitsioneeritud ja oleks võimalik kiired päringud ja tabelid ei läheks ebamõistlikult suureks. Temaatilised logid võib jagada äriliste protsesside mikroteenuste andmebaasidesse.

Kuna tegevuste logi võib tekkida väga palju, siis tuleks eelistada teist varianti. Logide vaatamiseks on võimalik kasutada logipingu koosseisu kuulutav kasutajaliidesega tööriista või arendada kasutajaliides, mille tagarakendus on integreeritud logipinuga läbi programmliidese.

Kuna auditlogide haldamiseks eraldi mikroteenust pole mõistlik teha, siis tuleks unifitseerida ja standardiseerida sääraste logide implementatsioon ja käsitleda seda eraldi tarkvarateegina. Auditlogi andmekomplekt peaks olema unifitseeritud ja sisaldama vajalikke andmevälju. Auditlogi kirjeid peaks olema võimalik seostada infosüsteemi dokumentatsiooniga, et auditi läbiviijatel teadmata täpselt äriloogikat oleks võimalik logikanne siduda äriprotsessi sammuga.

4.2.11. Avaandmete lüüs

Avaandmete lüüs on moodul, mille ülesanne on serveerida Interneti avaandmeid. Joonisel 7 on kujutatud avaandmete halduse tehniline lahendus.

Joonis 7 Avaandmete haldamine ja publitseerimine

Avaandmete lüüs peaks olema mikroteenus, mille ülesanne on süsteemi avaandmeid hallata. Avaandmete loomise eest vastutab valdkondlik mikroteenus (äriprotsessi mikroteenus vms.) Unifitseeritud ja sarnane funktsionaalsus tuleks koondada ühte tarkvarateeki ja seda kasutada avaandmete loomiseks valdkondlike andmete baasilt. Süsteemi äriprotsesside mikroteenused loovad oma valdkonna avaandmeid (vastavalt juhendile ) ja edastavad neid26

avaandmete lüüsile kasutades asünkroonset andmevahetusplatvormi. Avaandmete lüüs vastutab andmete säilitamise ja edasise esitamise eest. Avaandmeid saaks hoida staatilisel, ilmutatud kujul, kas plokkandmehoidlas või andmebaasis JSON vormingus. Esimesel juhul tuleb lisaks andmetele andmebloki salvestamisel säilitada andmebaasis bloki metaandmed. Andmebaasis andmete hoidmine võib olla siiski paindlikum ja anda tulevikus võimalusi näiteks otsinguid teostada avaandmete baasilt. Lõpliku ligipääsu avaandmetele päringute pinustamise ja piiramise eest vastutab juba programmliideste pääsulüüs.

Käesoleval viisil avaandmete säilitamine ja avaldamine võimaldab teostada enne andmete säilitamist isikuandmete anonümiseerimist ja võimaldab eraldiseisvalt operatiivandmebaasist neid andmeid väljastada. Andmebaasis andmete hoidmine kasutades dokument orienteeritud andmesalvestustehnoloogiat võimaldab ka üle andmete otsinguid teostada.

4.2.12. Kaardimoodul

Kaardimoodul on mikroteenus mille eesmärk on tegeleda georuumiliste ( ) andmetega.geospatial

Kaardimoodul on olemasolev tarkvara TTA SKI, millel on oma andmebaasid loogikakiht ja kasutajaliides. Antud süsteem tuleb integreerida piisavas mahus käesolevas dokumendis kirjeldatud mikroteenuste arhitektuurida kasutades samu põhimõtteid. Lõppkasutaja kasutajaliies saab uuendada ja taasluua kasutades loodava süsteemi disainimustrit ja arendamise põhimõtteid.

4.3. Andmevahetusmoodulid

Käesolevas peatükis tutvustame kommunikatsiooni ja andmevahetusmooduleid ja põhimõtteid, samuti pakume välja komplekti andmeahetusega seotud mooduleid ja nende kirjelduse.

Mikroteenuste arhitektuuri mustri arenedes on kogunud populaarsust REST ( ) andmevahetus põhimõte, mis baseerubRepresentational State Transfer HTTP protokollil. Mikroteenuste laiemal levikul sai sellest andmevahetuspõhimõttest standardmuster. Mikroteenuste arendus ja uute tehnoloogiate tekkimisega koos on loodud uusi protokolle ja andmevahetuse mustreid, mis koguvad üha populaarsust näiteks AMQP protokoll (Advanced Message Queuing Protocol), STOMP ( ), GraphQL, Simple Text Orientated Messaging Protocol Websocket.

4.3.1. Süsteemi komponentide andmevahetuse põhimõtted

Käesolevas peatükis sõnastame olulisemad süsteemi komponentide vahelised põhimõtted järgnevalt:

Süsteemi komponendid peaks eelistama omavaheliseks suhtluseks asünkroonseid protokolle sünkroonsete protokollide ees, näiteks tuleks kasutada AMQP protokolli; Süsteemi komponentide vahelises asünkroonses andmevahetuses tuleb luua standardiseeritud sõnumi formaat, mis sisaldab infot sõnumi osapoolte kohta, seansi metainfot ja vahetatav informatsiooni; Vahetatav info peaks olema JSON vormingus; Kui süsteemi komponendid kasutavad suhtlemiseks REST andmevahetust, siis toimub suhtlus läbi programmliidese pääsulüüsi; Süsteemi kasutajaliidesed peaks tagarakendustega suhtlema keerukamate andmevajaduste puhul eelistatult GraphQL seejärel REST andmevahetuse mustri abil, lihtsamate andmevajduste puhul piisab REST protokollist; Süsteemi kasutajaliidese ja tagarakenduste asünkroonseks suhtluseks sobiks kõige paremini STOMP või Websocket tehnoloogiad; REST teenused peaks olema lihttüüpidega (äriloogiliste olemitena), kusjuures tuleks rangelt välitda komineeritud lihttüüpide kohta pöörduspunktide tegemist, mis muudab programmliidese keerukaks ja raskesti hoomatavaks.

4.3.2. Süsteemi väliste osadepoolte andmevahetuse põhimõtted

Käesolevas peatükis sõnastame olulisemad süsteemi komponentide ja väliste süsteemide vahelise andmevahetuse põhimõtted järgnevalt:

Riiklikud süsteemid suhtlevad omavahel kasutades X-tee taristut; Käesoleval ajal on eelistatud kasutada X-tee taristul asünkroonset REST andmevahetust, kus vahetatakse andmeid JSON formaadis; Kõik seni SAOP protokollile arendatud X-tee teenused mida organisatsioon pakub viiakse arendusprotsessi kõigus üle REST lahendusele, selle kohta tuleb teisi osapooli teavitada piisavalt varakult, et need saad muudatusega adapteeruda; Süsteemi elukaare jooksul ei looda enam uusi SOAP teenuseid; SOAP teenuseid teenindatakse nende üleminekuni kasutades olemasolevaid tarkvarasid; Loodaval süsteemil on põhimõtteliselt valmisolek võtta kasutusele ka asünkroone X-tee andmevahetuspraktika, kuid selle arendamine ja välja töötamine X-tee platvormil alles käib. Süsteemi osapoolte, kes ei kasuta X-tee päringuid ja süsteemi vahel on võimalik kokku leppida ja avada ka programmliideseid, mingis konkreetses äriprotsessis osalemiseks.

4.3.3. Programmliideste pääsulüüs

Kogu süsteemi üks keskne kommunikatsiooni moodul on programmliidese pääsulüüs ( ), mille põhiliseks ülesandeks on vahendadaApplication Gateway andmevahetuspäringuid süsteemi komponentide vahel (v.a. asünkroonsed AMQP päringud). Detailsemad ülesanded ja võimalused on loetletud järgnevalt:

Päringute vahendamine õigele ressursile (mikroteenusele); Päringute autoriseerimine – õiguse tuvastamine teha päringut; Päringute transformeerimine – andmete manipuleerimine päringus/vastuses vastavalt vajaduele; Päringute paigutamine pinusse – kiiremaks vastamiseks ( );caching Protokolli transformeerimine – nt REST-GraphQL; Päringute filtreerimine; Päringute monitoorimine;

Nimekiri pole lõplik.

Programmliidese pääsulüüsi oluline funktsionaalsus on päringute autoriseerimine ja see funktsionaalsus peaks olema just programmliidese pääsulüüsis, mitte igas mikroteenuses eraldi. Mikroteenuses peaks olema päringute autoriseerimine ainult erandkorras.

Programmliidese pääsulüüsiks tuleks kasutada vabavaralist valmistarkvara KrakenD . Kõnealusel tarkvaral on tugi mitmesuguste teiste27

kommunikatsiooni lahendustega koos töötamiseks sh. tugi autoriseerida päringuid vastu identiteedi ja pääsuhalduse moodulit Keycloak. Kõik kommutaatori ( ) funktsioonid konfigureeritakse seadete failidega ja neid saab hoida ja versioneerida GIT repositooriumis. Rakendusele on võimalikrouter kirjutada vajadusel laiendusi vastavalt organisatsiooni vajadustele, mis muudab tarkvara paindlikumaks.

Alternatiivina nimetatud valmistarkvarale on võimalik pääsulüüs ka arendada kasutades aredusraamistikku. Näitena võib kasutadaJava Spring Boot TEHIK TeIS projektis arendatud tarkvara .common-api-gateway28

4.3.4. X-tee moodul

X-tee mooduli ülesandeks on vahendad X-tee päringuid sisemiste komponentide ja välimiste süsteemide vahel. X-tee poolt vaadatuna on moodul, kui X- tee adapter, süsteemi seest vaadatuna on tegemist X-tee suhtlemist abstraheeriva pääsulüüsiga.

X-tee moodul sisaldab äriloogikat, mis on vajalik konkreetsete päringute teenindamiseks või informatsiooni kogumiseks. Näiteks eksisteerib hetkel selliseid x-tee teenuseid, kus andmete saamiseks on vaja kasutada kahte erinevat päringut. Ühte selleks, et andmete saamist algatada, teist selleks, et andmed alla laadida. Teisalt on selliseid päringuid, kus päringu esmakordsel tegemisel tagastatakse mingi identifikaator ja algatatakse info saamine ja sama päringu kordamisel koos identifikaatoriga on võimalik andmete tekkimisel andmed kätte saada. Sellisel juhul tuleb päringute korduv tegemine ja andmete ootamine realiseerida x-tee mooduli äriloogika protsessina. Antud tegevust on teoreetiliselt võimalik realiseerida ka protsessimootori kaasamisega, kuna antud tegevuste jada on küllaltki lihtne tegevuste algoritm. Selline lähenemine looks aga lisakeerukust moodulisse endasse.

X-tee moodul peaks olema Java keeles arendatud tarkvara või TEHIK TeIS projekti arendatud kloon.xroad-gateway29

4.3.5. Asünkroonsete sõnumite vahetuskiht

Asünkroonseks andmevahetuseks tuleb eelistada AMQP andmevahetusprotokolli, mille vahendamiseks tuleb süsteemi paigaldada RabbitMQ klaster. Klastri saab paigaldada Kubernetes platvormile.

Pakume välja ka asünkroonse andmevahetuse implementatsiooni, mis on kujutatud joonisel 8.

Joonis 8. Asünkroonse sõnumivahetuse arhitektuur raamistiku näitelSpring Boot

Süsteemis on keskne RabbitMQ vahendaja ( ). Temasse luuakse andmevahetuskanal ( ) kuhu iga liitunud osapoole kohta luuaksebroker exchange sõnumijärjekord ( . Süsteemi üleselt lepitakse kokku standardses andmevahetussõnumis, mis sisustatakse andmetega ja edastatakseque) andmevahetuskanalisse. Andmevahetussõnumisse pannakse kaasa ka saatja ja adressaadid. Moodulid mis on liitunud andmevahetuskanaliga võtavad sõnumi vastu, kui nad on adressaadid. Süsteemi siseselt toimub siis juba info edastamine õigele teenuse implementatsioonile. Java Spring Boot raamistikus on võimalik rakenduse sees saata sündmuseid ( ) ja teenusklassid saavad vastavalt sündmuse tüübile (näiteks adressaadi poolt väljaevent kutsutud operatsioon) andmed vastu võtta. Kogu sõnumite saatmise ja vastuvõtmise tarkvaraline implementatsioon peaks asuma keskses teegis, mida saab sõltuvusena tarkvaraprojektidesse lisades ja koheselt kasutusele võtta.

4.4. Andmemoodulid

Käesolevas alapeatükis käsitleme süsteemi komponente, mida saab klassifitseerida andmete põhiselt või on seotud andmete hoidmisega ja teistele mikroteenustele kättesaadavaks tegemisega.

4.4.1. Andmebaasimootor

Süsteemi põhiliseks andmebaasi mootoriks on PostgreSQL. Andmebaasi mootori evitus on kirjeldatud täpsemalt peatükis .5

4.4.2. Põhiandmete pääsulüüs

Antud dokumendis toodud arhitektuur, ei sätesta lõpplikku mikroteenuste arvu seetõttu, et ei ole kuidagi reguleeritud mikroteenuste skoop, mis sisaldavad äriprotsesse. Kui sõnastada mikroteenus, kui eraldiseisev paigaldatav üksus, siis võib igat mikroteenust eksisteerida ka n-1 paigaldatud instantsi (skaleeritud rohkem kui üks instants). Äriprotsesse võib grupeerida mikroteenusteks liigi, või muude tunnuste järgi. Mikroteenuste arhitektuuri üks põhimõte on, et igal mikroteenusel on oma andmebaas või pole seda üldse. Teised mikroteenused pöörduvad mikroteenuse andmetele ainult läbi mikroteenuse programmliidese.

Kuna aga erinevad äriprotsessid vajavad ja toodavad põhiandmeid sõltumatult, tekib probleem kuidas andmeid hoida selliselt, et andmed ei oleks laiali üle äriprotsessi mikroteenuste andmebaaside ja andmete ligipääs oleks lihtne.

Selleks on mõistlik luua eraldi mikroteenus, mis tegeleb põhiandmete hoidmise ja käsitlemisega. See mikroteenus ei sisalda äriloogikat ja vahendab ainult andmete salvestamist andmebaasimootorisse ja erinevaid otsinguid andmetest. Selline lahendus sobib eelkõige põhiandmetele, mis ei ole transaktsiooniliste omadustega või raamatupidamislikud. Eelkõige sobib selline lähenemine staatiliste andmete sh. dokument tüüpi andmekomplektide vahendamiseks ja hoiustamiseks.

Näitena tooks olukorra, kus on andmekomplekt „tegevusteade”. See on põhiandmete komplekt, milline on eraldiseisvalt põhiandmete komplekt, mis sisaldab olulist informatsiooni kogu äriprotsessi jaoks. Sarnase olemusega eksisteerib aga mitmeid andmekomplekte, mis samas on aga natukene erinevad. On olemas mikroteenused „kasutajaliides”, „menetlus-protsess”, „teavitus” ja „andmete lüüs”. Menetlus-protsess koostab kasutajaliidese päringu peale uue „tegevusteade” andmekomplekti, eel-täidab teatud andmeväljad ja edastab kasutajaliidesesse. Kasutajaliides täiendab andmekomplekti ja saadab tagasi menetlus-protsess mikroteenusele. Menetlus-protsess mikroteenus teab, mis tegevusi edasi peab tegema, kuid üks samm on, et tuleb salvestada tegevusteate andmed. Selleks saadab „tegevusteade” andmekomplekti andmete pääsulüüsi, mis paneb andmed andmebaasi. Lisaks pöördub menetlus-protsess ka veel „teavitus”, poole, et välja saata info uuest tegevusteatest. Sellega on protsess lõppenud. Protsess võib olla lõppenud, kuid kasutajaliides soovib uuesti saada kätte „tegevusteade” andmeid, selleks pöördub kasutajaliides otse andmete lüüsi poole ja saab sealt õige info kätte.

4.4.3. Pinumälu ( )cache

Pinumälu eesmärk on ajutiselt salvestada andmeid kiireks pöördumiseks ja jagamiseks. Pinumälu peamiseks omaduseks on, see et andmeid hoitakse mälus mitte kettamassiividel, ning andmete saamine pinust toimub võrreldes andmete saamisega andmebaasist kiiresti. Pinumälu omaduseks on ka asjaolu, et selle poole saab pöörduda mitmesuguseid kliente kes kõik vajavad sama andmestikku.

Pinumäluks tuleb kasutada Redis pinumälu süsteemi.30

4.4.4. Andmete indekseerimine

Andmeid on vaja indekseerida eelkõige selleks, et kiirendada nendest osa leidmist. Praktikas näiteks täisteks otsingud, sõnaosa otsingud, täppisotsingud. Andmete indekseerimine ja indeksilt tehtavad otsingute funktsionaalsused eksisteerivad juba olemasolevas süsteemis ja see tuleb üle viia uude platvormi. Kuna olemasolevas lahenduses on kasutusel Elasticsearch tarkvara, tuleb seda jätkuvalt kasutada ka uuel arhitektuuril. Indeksandmete hoidlaks tuleb31

kasutada tarkvara. pakub andmete sisestamiseks ja pärimiseks REST teenust ja erinevates programmeerimise raamistikes onElasticsearch Elasticsearch üldjuhul tugi valmis kujul olemas. Nagu näiteks Java Spring Boot raamistiku puhul.Elasticsearchi

Sarnaselt Relatsioonilisele andmebaasile tuleks indeksandmebaas evitada virtuaalmasinale, mitte Kubernetes klastris.

4.4.5. Pseudonüümimise moodul

Pseudonüümimise moodul on mikroteenus, mille ülesanne on korraldada süsteemis andmete anonümiseerimist ja pseudonümiseerimist. Esineb olukord, kus andmed pärast andesubjekti surma või ärilise aktuaalsuse kadu tuleb pseudonümiseerida. See tähendab, et andmesubjekti isikuandmed asendatakse initsiaalidega või pseudo-informatsiooniga.

Käesolevas moodulis hoitakse pseudonümiseerimise ärireeglid ja moodul etteantud ajal käivitamisel läheb ise ette antud andmebaasi ja käivitab seal pseudonümiseerimise algoritmi, mille tagajärjel andmed anonümiseeritakse või pseudonümiseeritakse.

Moodul peaks olema Java keeles arendatud tarkvara. Tarkvara käivitatakse koordindeeritult vastavalt vajadusele ja see ei pea töötama kogu aeg.

4.4.6. Andmete sünkronisaator moodul

Olukorras, kus eksisteerib lisaks uuel platvormil arendatud süsteemile ka vana ja teatud funktsionaalsus on arendatud uuel, samas osa vanal peab andmeid süsteemide vahel sünkroniseerima. Sellisel juhul tuleks arendada sünkroniseerimise moodul, mis võtab andmeid uuest andmebaasist (uuel andmemudelil), teisendab andmed ja sisestab need vaba andmebaasi (vanal andmemudelil). Sünkroniseerimise sammuks võib olla ka andmete transformatsioon. Näiteks viiakse andmed üle JSON vormingust EVA mudelile ja vastupidi.

Andmete sünkronisaator moodul peaks olema Java keeles arendatud tarkvara.

4.5. Äriprotsessi moodulid

Käesolevas peatükis kirjeldame täpsemalt võimalikke äriprotsessi mooduleid, protsessimootorite kasutamise põhimõtteid ja äriprotsesside programmeerimist juhul, kui neid ei implementeerita protsessimootori abil.

4.5.1. Protsessimootori kasutamise põhimõtted

Protsessimootori kasutamise olulisemad põhimõtted on alljärgnevad:

Protsessimootorit käitav mikroteenus peab sobituma käesolevas dokumendis kirjeldatud mikroteenuste arhitektuuriga; Protsessimootorit käitav rakendus oleks ühtlasi ise mikroteenus; Protsessimootorit võib rakendada mitmes rakenduses; Protsessimootori poolt käitavat protsessi peab olema võimalik laadida andmebaasi ja rakendus peab saama seda andmebaasist laadida; Äriprotsessi modelleerimiseks peaks olema võimalik kasutada ette antud funktsioone, mis on arendatud töötama koostöös protsessimootoriga;

Joonisel 9 on kujutatud, mil viisil võiks protsessimootorit käesolevas dokumendis kirjeldatud mikroteenuste arhitektuuril arendatud mooduli kasutada.

Joonis 9 Protsessimootori mikroteenuse moodulis kasutamise põhimõtteskeem

Üks levinud protsessimootori lahendus on Camunda , mida saaks integreerida käesolevas dokumendis kirjeldatud mikroteenuste arhitektuuril arendatud32

äriprotsessi moodulitega või keskse protsessimootori mooduliga. Camunda kasutamine sellisel juhul oleks manustatud ( ) lahendusena.embedded

4.5.2. Võimalikud eraldiseisvad ärimoodulid

Järgnevalt loetleme võimalikud äriprotsessi moodulid, mis tulenevad olemasolevate süsteemide äriprotsessidest ja andmestikust. Need on alljärgnevad:

Aadresside haldus - moodul mis võimaldab pidada arvestust aadresside üle ja liidestuda Maameti ADS süsteemiga. Antud moodulit võiks ka kaaluda liita administratiivse vms mooduliga; Dokumentide haldus (DHS) - klassikalise dokumendihalduse moodul; Haridus ja tunnistused - moodul, kus hallatakse äriprotsessides registrites töödeldava haridusega seotud andmeid; Koolitusload - moodul, kus hallatakse koolituslubade andmeid ja vastavaid äriprotsesse; Keelud - Äriliste keeldudega seotud äriprotsesside ja andmete halduse moodulid; Statistika - Moodul mis võimaldab koguda ja andmelattu edastada statistilisi andmeid, põhifookus statitsilistel mudelitel peaks asuma andmeaidas; Kasutajate tagasiside - moodul kus hallatakse avalike kasutajate tagasiside andmeid; Taotlused - moodul mis töötleb erinevaid taotluseid ja vastutab andmete säilitamise eest; Teated - moodul mis töötleb erinevaid tegevusteadeid ja vastutab andmete säilitamise eest; Load - moodul mis töötleb erinevaid lubasid ja vastutab andmete säilitamise eest; Tegevuskohad - moodul mis töötleb erinevaid tegevusteadeid ja vastutab andmete säilitamise eest; Äriprotsessi logi - moodul kuhu koondatakse äriprotsessi logi; Numbriliikuvus - numbriliikuvuse moodul; Numbrilubade haldus - numbrilubade halduse moodul; Tarbijavaidluste haldus - tarbijavaidluse andmete ja protsesside haldamsie moodul; Raadiosagedused ja side - raadiosageduste ja side alaste protsesside moodul; Energiaaudit - erergiaauditite protsesside ja andmte haldamise moodul; Ettekirjutused ja järelevalve - ettekirjutuste ja järelevalve protsesside ja andmete moodul; Kemikaalid - kemikaalidega seotud äriprotsesside ; Sündmused - sündmuste keskse halduse ja äriprotsesside moodul; Aruandlus - Aruandluse andmete ja äriprotsesside haldamise moodul; Väärteomenetlus väärteamenetluste läbiviimise ja selelga soetud andmete moodul;

Nimekiri pole lõplik ega ammendav. Lähtuvalt olemasolevate süsteemide andmemudelitele, on võimalik ja tuleks tungivalt kaaluda sarnaste äriprotsesside andmete ja funktsionaalsuste konsolideerimist nii äriarhitektuuris, kui andmearhitektuuris.

4.6. Kasutajaliidese moodulid

Käeolevas peatükis käsitleme kasutajaliidestega seonduvat. Käsitleme kasutajaliideste temaatikat mikroteenuste arhitektuuris, mikrokasutajaliideste mõistet, ksutajaliideste disainimustreid ja vahendeid, majutusarhitektuur ja andmevahetust tagarakendustega.

4.6.1. Mikrokasutajaliidesed

Mikrokasutajaliidesed ( ) on tihti segadus tekitav termin, mis meie hinnangul on ka tegelikult üsna laiali valguv määratlus. MikroteenusteMicro front ends arhitektuuris on rõhk sõnal teenus, siis selle mõte on olnud alati jagada monoliitset infosüsteemi funktsionaalseteks osadeks (mikroteenusteks), mingite tunnuste, funktsioonide kaupa või organisatoorsete aspektide tõttu. Selle resultaat on, et tekib tagarakendus oma isikliku andmeaasiga. Seda võib IT maailmas nimetada nähtuste eraldamiseks ( ). Kuid kas sama praktikat peaks ja saaks rakendada ka kasutajaliidestes? Mitte alati,separation of concerns vähemalt mitte samal viisil.

Joonisel 10 on kujutatud mikrokasutajaliideste jaotus mingiks kujutletavaks nähtuseks. Siin on tegelikult jaotus enamjaolt tehtud mingite äriliste tööliinide kaupa, mitte mikro-funktsionaalsuste või olemite kaupa. Lihtsalt selline lähenemine, et on igal mikroteenuse tagarakendusel on ka oma mikroteenusest kasutajaliides ei toimi. Üldjuhul on vaja kasutajaliideses näidata andmeid ja töödelda neid kombinatsioonis mitme mikroteenuse andmestikuga. nt Isik ja tema Konto vms.

Joonis 10. Nähtuste eraldamine mikrokasutajaliideses.33

Oluline on aga silmas pidada, et kasutajaliideses ei pruugi toimida nähtusteks eraldamine samadel alustel, kui tagarakendustes ja andmebaasides. Kasutajaliideses tuleb tagada lõppkasutajale mugav ja arusaadav lahendus, mis aga tähendab, et mingite objektide või funktsioonide kaupa ei puurgi saada rakendust jagada. Seega liigub kasutajaliideste arendus üldse mikroteenustest eraldi ja kasutajaliidese arendamisel ei pruugi mikroteenuste olemasolu või jaotus üldse oluline olla, sest kontaktpunkt on üldse programmliides. Selles punktis on võimalik andmeid mitmetest mikroteenustest agregeerida, et vähendada liiklust kasutajaliidese ja mikroteenuste vahel.

Üks levinud arusaam, mis mikrokasutajaliidestega on kaasneb on, et mikrokasutajaliides on eraldi paigaldatav. Kuid pigem on oluline omadus efektiivne arendusvõimekus (organisatoorne). Omadus, et igat mikrokasutajaliidest võib arendada eraldi meeskond. Praktikas on mikrokasutajaliides lõpptarbija jaoks eraldiseisev JavaScript koodifail. Iga mikrokasutajaliides on pakitud eraldiseisvasse füüsilisse JavaScript faili ja seda käivitatakse ainult vastava funktsionaalsuse käivitamiseks. See ei pea muidugi tähendama, et antud mikrokasutajaliides JavaScript fail, koos muude lisadega on pakitud eraldiseisvasse paigaldatavasse konteinerisse.

Mikrokasutajaliideste jaotusel peab pigem arvestama asjaolusid, et erinevad meeskonnad saaks efektiivselt tegutseda ja oma äriprodukte arendada segamata üksteist ja omamata jäiku seoseid. Praktikas tähendab see, et on kasutusel mitmed Git repositooriumid ja ühiskasutatavad üldkomponendid on pakitud kasutajaliidese teekidesse ja kasutatud läbi sõltuvuste lahendamise tehnoloogia NPM ( ).Node Package Manager

Vertikaalselt meeskondadeks ja tööliinide gruppideks jaotamise näide on toodud joonisel 11.

Joonis 11 Mikrokasutajaliidete vertikaalne jagunemine34

Kasutajaliideste arendamisel tuleks järgida organisatsioonis paika pandud disaini ja kasutajamugavuse mustreid, taaskasutada ja hallata ühtseid lihtsamaid komponente. Igal komponendil peab olema vastutaja ( ).code owner

Evituse vaatest ei pruugi mikrokasutajaliides tähendada eraldi seisvat paigaldatavat ühikut - Docker konteinerit. Liigse halduskeerukuse vältimiseks võiks mikrokasutajaliidesed siiski paketeerida üheks, kuni kaheks paigaldatavaks komponendiks. Paketeerimise aluseks võib olla ka asjaolu, et teatud funktsionaalsus on kasutatav ainult organisatsiooni sisevõrgus ja sellele ressursile ligipääs tuleb piirata võrgu tasemel.

Joonisel 12 pakume välja mikrokasutajaliideste põhiprintsiibid, kus oleme toonud ühele pildile nii, mikrokasutajaliideste jaotuse lähtekoodi hoidlas, kui ka kasutajaliideste evituse Docker konteinerina.

Joonis 12 Mikrokasutajaliideste põhimõtteline jaotus arenduses ja evitus majutusplatvormil.

Põhimõtted on järgnevad:

Üldkasutatavad komponendid arendatakse ühes (monorepo) või mitmes repositooriumis ja paketeeritakse NPM pakiks. Pakki hoitakse artifaktooriumis; Üldkasutatavatel komponentidel on üks konkreetne koodiomanik ( ). Muudatustesse võivad panustada kõik osapooled;code owner

Erinevates Git repositooriumites hoitakse erinevate lõpp-kasutajaliideste koodi; Koodi ehitamisel lõpptarkvaraks (staatiliseks koodiks) kaasatakse üldkasutatavad komponendid NPM artifaktooriumist sõltuvusena; Teistest moodulitest dünaamiliselt või staatiliselt koodi või funktsionaalsust ei kasutata; Lõplik staatiline kood paketeeritakse kokkusurutud pakendisse ja hoitakse artifaktooriumis; Paigaldatav konteineri pilt (Docker image) koostamisel laetakse sinna sisse artifaktooriumist mikrokasutajaliideste koodipakid, pakitakse lahti ja serveeritakse veebiserveriga; Kuna antud lähenemisel iga erineva mikrokasutajaliidese Interneti sirvikusse laadimisel uuendatakse kogu sisu, siis võimalik sessiooni info või muu oluline meta-info mida on vaja teenusest teenusesse üle anda salvestatakse sirvikus kasutades Redux hoidla võimalusi.35

Oluline on silmas pidada, et antud lähenemise tulemusena ei teki väga palju kasutajaliidese konteinereid, mis hõlbustab administreerimist. Arvestades seda, et kirjeldatud visiil pakitud kasutaliideste tarnimine ja uuendamine on lihtne ja ajaliselt lühike tegevus, siis pole mõistlik jagada mikrokasutajaliideseid eraldi konteineriteks. Suure hulga konteinerite tekkimine raskendaks üldist evitust ja selle administreerimist.

4.6.2. Kasutajaliidese disainimustrid ja -vahendid

Süsteemi kasutajaliideste disainimustriks tuleks kasutada Veera disainisüsteemi . See on üks kolmest riiklikust disainisüsteemist, mille eesmärk on36

pakkuda kasutajale ühtest kasutajakogemust unifitseeritud stiiliraamistikus. Veerast on mitu versiooni ja paralleelseid koopiaid, nii kui ja Angular React raamistikele.JavaScript

4.6.3. Andmevahetus tagarakendustega

Andmevahetuseks tagarakendustega on kasutajaliidestel mitmeid võimalusi näiteks REST, Websocket ja GraphQL. Need kolm tehnoloogiat pole ükskõik sarnane, kuid võivad kombinatsioonis tõsta teenuse kvaliteeti ja süsteemi töökindlust.

REST teenus on enamlevinud ja väga populaarne lahendus. REST puhul tuleks igat olemit käsitleda ühe pääsupunkti grupina (vaatamine, muutmine, lisamine, kustutamine) mistõttu võib pöörduspunktide arv kasvada väga suureks ja seetõttu ka programmliideste spetsifikatsioon muutuda keeruliseks ja hoomamatuks. Kui ühe korraga on vaja küsida tagarakendustest (ühest) või mitmest korraga andmeid üheaegselt, siis REST puhul tähendab see mitme päringu paralleelset või järjestikulist käivitamist.

GraphQL on tehnoloogiana kiire, võimaldab unifitseeritud viisil teha andmemuudatusi ja päringuid, süsteemide suunas, kusjuures pole oluline milline on täpne tagarakenduste topoloogia. GraphQL tehnoloogia kasutamine võib lihtsustada programmliidest, kuid selle tehnoloogia enda kasutamine on mõnevõrra keerulisem kui REST puhul. Selle õppimine ja oskusteabe omandamine nõuab arendajatelt rohkem pingutusi kui REST puhul, kuid see pingutus toob kasu teistes kohades.

Websocket tehnoloogia kasutamist tuleb kaaluda kohas, kus kasutajaliidesele on vaja edastada infot tagarakenduse algatusel. Näiteks on selle tehnoloogia rakendusvaldkond reaalaja vestlusaknad.

4.7. Olemasolevad tarkvarad

JvIS – Järelevalve Infosüsteem. PHP Symfoni raamistikul arendatud monoliitne, PostgreSQL andmebaasiga.

MTR – Majandustegevuste Registri infosüsteem. PHP Symfoni raamistikul arendatud monoliitne, PostgreSQL andmebaasiga.

NBA/SASS – Numbribroneerimise ja numbrilubade halduse infosüsteem.

SKI (AlphaGIS) – Kaardirakendus, mida arendatakse ja täiendatakse eraldiseisva projektiga.

Andmeait - TTJA suurandmete andmeait, mida arendatakse ja täiendatakse eraldiseisva projektiga.

Kõesolevas dokumendis toodud mikroteenuste arhitektuuri praktilisel rakendamisel tuleks täiandada ja edasi arendada ka olemasolevaid süsteeme. Neile tuleks luua kesoelvas dokumendis nimetatud kommunikatsioonipaltvormide toed REST teenused ja AMQP suhtluse võimekus.

5. Majutusarhitektuur Käesolevas peatükis kirjeldame süsteemi majutamist ja majutamisega seotud küsimusi, kontseptuaalset, evitust, majutusplatvormi ja -tööriistu.

5.1. Kontseptuaalne evitus

Kontseptuaalset evitust kirjeldab evitusdiagramm joonisel 13. Potentsiaalselt evitatakse süsteem virtuaalmasinatel ja Kubernetes klastris. Virtuaalmasinatel evitatakse andmebaasimootor PostgreSQL. Mikroteenused ja toetavad komponendid majutatakse Kubernetes klastris. Erinevad põhimõttelised komponendid või halduspartnerite vastutusalad eraldatakse Kubernetes nimeruumidega (N ). Rakendustele luuakse paigaldusüksused (amespace Deploym

), võrguteenused (services), konfiguratsioonid ( ). Käivitatud konteinerid ( ) töötab Kubernetes õla ( ) serveri protsessina. ent Configurations Pod Node

Joonis 13. Kontseptuaalne evitusdiagramm.

Evituses on kujutatud ka logimine ja monitooring, millest täpsemalt on kirjutatud peatükkides.  ja 5.2.3. 5.2.4.

5.2. Majutustööriistad

Käesolevas peatükis kirjeldame detailsemalt süsteemi majutamiseks olulisi tööriistu ja tarkvarasid. Kirjeldame pilveplatvormi Kubernetes, Pideva paiggaldamise, monitooringu ja tehnilise logimise tarkvarasid.

5.2.1. Pilveplatvorm Kubernetes

Kubernetes on avatud lähtekoodiga konteineritesse pakitud rakenduste automaatse paigalduse, ressursi planeerimise, skaleerimise ja halduse süsteem.37

Kubernetes on muutunud majutuskeskkonnaks erinevas suuruses ettevõtete ja organisatsioonide poolt. Selle platvormiga on võimalik majutadade fakto mikroteenustel baseeruvat arhitektuuri ja tagada kõrgkäideldavus.

5.2.2. Pideva paigaldamise tarkvara

Pideva paigaldamise tööriistaks pakume eelkõige Argo CD tarkvara. Antud tarkvara paigaldatakse Kubernetese klastrisse ja sellega hallatakse38

Kubernetes klastri komponente. Põhiline erisus vanamoodsa lahendusega on see, et kui varasemalt on olnud valdav, et Gitlab juhtkanalid vajavad pääsu Kubernetes klastrisse ja algatavad muudatused, siis uue lähenemise puhul CD tegevusi otseselt ei algata Gitlab, vaid Kubernetes klastris asuv Argo CD käiv ise kontrollimas Gitlabi konfiguratsiooni repositooriumis, kas on muudatusi. Vajadusel saab teha Veebikonkse ( ), et teavitada CD süsteemiweb-hook toimunud muudatustest. Küll aga nimetatud lähenemine ei vaja üldse CD juhtkanalite loomist. Pideva paigaldamise tarkvaraga kasutamisega on tagatud ka GitOps põhimõtted, millest on täpsemalt kirjutatud peatükis . Samuti järgib see lähenemine Kubernetes operaatori mustrit ( )9.2 Operation Pattern 39

5.2.3. Monitooring

Süsteemi hetkeolukorra, alusplatvormi jõudluse ja rakenduste vaatlusparameetrite reaalajast hetkeolukorra jälgimiseks ning vajalike häiresignaalide väljastamiseks huvitatud osapooltele tuleb kasutusele võtta monitooringu moodulid-mikroteenused. Käesoleval ajal on valdkonnas üldpopulaarsed ja levinud tööriistad Micrometer teek, Prometheus monitooringu tsentraalne agregaator ja Grafana monitooringuinfo visualiseerimise tööriist. Joonisel40 41 42

14 on kirjeldatud mikroteenuste monitooringulahendus Kubernetes majutusplatvormil kasutades nimetatud tööriistu.

Joonis 14 Monitooringu tööriistade põhimõtteskeem Kubernetes majutuses

Suures süsteemis on oluline ka skaleerimine, selle eest peab hoolt Kubernetes horisontaalne automaatne skaleerimise funktsionaalsus (Horizontal Pod ) edaspidi HPA. HPA seadistatakse töötama vastu Prometherus adapterit, kust saab töötava rakenduse konteineri reaalajalise info. VastavaltAutoscaler

seadistustele ja etteantud limiitidele skaleerib PHA vajadusel rakendust – lisab või vähendab õlgasid. Juhul kui on kasutusel klastri GitOps operaator, siis on võimalik HPA funktsionaalsust rakendada ka selle kaudu. Eelnimetatud lahendus oleks eelistatud siis, kui klastri GitOps operaatorit kasutusel poleks.

5.2.4. Tehnilised logid

Süsteemi tehniline logi on äärmiselt vajalik saamaks aru süsteemi toimimisest ja eriti, siis kui süsteemis on veaolukorrad või tõrked. Tarkvaravigade silumiseks on tarkvaraarendajal vajalik pääseda ligi logidele. Keerulistest süsteemides tuleb logisid käsitleda ühtse tervikuna, kuna päringud ja andmed läbivad mikroteenuseid ja protsesse. Kogu tervikust ilma korraliku logisüsteemita pole võimalik aru saada. Joonisel 15 on kujutatud meie poolt välja pakutud tehnilise logi kogumise ja logide kesksüsteemi edastamise lahendus.

Joonis 15 Tsentraalne logimine

Kubernetes klastris on igal rakenduse õlal sõltuvalt klastri konfiguratsioonist logifail, mis asub Kubernetes serveri failisüsteemis. Logi eksisteerib seni, kuni rakenduse õlg eksisteerib. Et vältida potentsiaalset logide kaotamist (selle risk on äärmiselt kõrge), tuleb logid deponeerida automaatselt kesksüsteemi, kus on neid võimalik keskselt kasutada ja analüüsida. Logide transportimiseks tuleks paigaldada Kubernetes klastrisse Fluentbit süsteemne protsess,43

mis kogub logid kokku serveri failisüsteemist ja edastab logid kesksesse logiserverisse.

5.3. PostgreSQL andmebaasi kõrgkäideldatav evitus

Tänapäeval on normaalsus, et süsteemid on kõrgkäideldavad. Seda nii rakenduste tasemel, kus kasutame Kubernetes klastrit, kui ka andmebaasides. Kuigivõrd me ei soovita andmebaasi mootorit majutada Kubernetes klastris soovitame andmebaasimotoorit majutada eraldiseisvas virtuaalmasinas ja kahe sellisega koostöös on võimalik saavutada kõrgkäideldavus. Joonisel 16 on kujutatud Kõrgkäideldava PostgreSQL andmebaasiklastri evitusjoonis.

Joonis 16. Kõrgkäideldava PostgreSQL klastri kontseptuaalne evitusjoonis

Kuigivõrd Kõrgkäideldava andmebaasiklastri käivitamniseks on mitmeid viise soovitame selleks kasutada voogedastuse replikatsiooni (Streaming ), kus keskseks replikaatoriks on vabavatraline tarkvara Patroni .Replication 63

Jooniselt lähtub, et tuleks kasutusele võtta kahe individuaalse virtuaalmasinaga süsteem, mis võivad asuda erinevates võrkudes ja või füüsilistes asukohtades. Üks n.ö. toodangu server ja teine test server. Sellisel viisil ei pea kulutama ressurssi toodangu süsteemile kahe virtuaalmasina paigaldamiseks. Küll aga tuleks selline lähenemine läbi arutada infoturbe vaatest. Lubada toodangu päringud test võrku on infoturbeline otsus. Tavaolukorras suunab Kubernetes klastrisse paigaldatud HA Proxy (ainult andmebaasimootorile) päringud toodangu suunas, kui toodangu pole enam kätte saadav lülitab proksi päringud automaatselt ümber kuumas valimiduses skeundaarse andmebaasiserveri suunas.

Serveritele paigaldatakse vabavaraline Patroni tarkvara, mis korraldab ja haldab replikeerimist läbi WAL kataloogi (PostgreSQL spetsiifiline funktsionaalsus).

5.4. Infrastrutkuuri esialgne indikatiivne vajadus

Käesolevas alampeatükis toome välja esialgse indikatiivse riistvara vajaduse kogu süsteemi tarbeks.

Kubernetes klaster

Vähemalt kolm õlga, e. kolm serverit, mille igaühe parameetrid on alljärgnevad:

Kõvakettapinda: 20GB Mälu: 16GB protsessori lõime: 8 

Andmebaasi klaster

Vähemalt kaks õlga,  e. kaks virtuaalmasinat, mille igaühe parameetrid on alljärgnevad:

Kõvakettapinda: 50GB Mälu: 8GB protsessori lõime: 16 

Elasticsearch virtuaalmasin

Kõvakettapinda: 100GB Mälu: 16GB protsessori lõime: 4

Pilw.io blokkandmehoidla

Prognoositav maht kohe pärast migreerimist: 1TB

JvIS - 800GB MTR - 100GB

Käeolev infikatsioon ei sisalda logide käitlemist. Logide käitlemiseks tuleks teha eraldi indikatsioon, kuid selle süsteemi kõvakettamaht on prognoositav sadades gigabaitides kuni terabaitides.

6. Andmeturve põhimõtted ja ülevaade Käeolevas peatükis käsitleme andmeturbe põhimõtteid ja kontseptsioone.

6.1. Andmeturbe põhimõtted

Süsteemi arendamisel ja haldusel tuleb järgida Eesti infoturbestandardeid Infosüsteemide turvameetmete süsteem ISKE ja Eesti Infoturbestandardit .44

Nimetatud dokumentidest viimane on uuem ja kaasaegsem. Süsteemi arenduse ja testimise käigus tuleks süsteemi kontrollida vastu OWASP Application Security Verification Standard , mida on võimalik ka automatiseerida ja kaasata süsteemi jätkuva integratsiooni protsessi. MKM-is kehtivad mitmed45

infoturbe küsimusi kitsamalt käsistlevad poliitikad, mis on loetletud järgnevalt:

Krüptokontseptsioon Logimisekontseptsioon Teenuste turvaline seadistamine Võrgukontseptsioon

Nimetatud poliitikad on täpsemalt kirjeldatud MKM-i Confluence keskkonnas. 

6.2. Andmekogude tsoneerimine

ISKE võimaldab andmekogusid tsoneerida. Selleks tuleks füüsiliselt eraldada osad mikroteenused või andmebaasid teistest. Kõrgema turvaosaklassiga andmed koondatakse ühte füüsiliselt eraldatud „tsooni”. Kubernetes majutuskeskkonnas on võimalik eraldada rakendusi eraldi tsoonidesse kasutades nimeruumide loogikat. Andmebaasides on võimalik tsoone luua andmebaaside või andmebaasi skeemide kaupa.

7. Tarkvara arendamise ja testimise metoodikad ja praktikad Käesolevas peatükis kirjeldame tarkvara arendamise ja testimist mikroteenuste arhitektuuril arendatud tarkvaraprojektide erinevates faasides.

7.1. Tarkvara arendamise ja projektijuhtimise metoodika

Tarkvaraarenduse protsessis on mitmeid metoodikaid ja lähenemisi. Meie soovitame mikroteenustel baseeruva süsteemi arendamiseks ja haldamiseks kasutada SCRUM metoodikat. SCRUM on kergekaaluline, kuid sellegi poolest võimas kooslus väärtustest, põhimõtetest ja praktikatest. Scrum toetub46

multi-funktsionaalsetele meeskondadele, et tarnida tooteid ja teenuseid lühikeste iteratsioonidena võimaldades alljärgnevaid asjaolusid:

Kiire tagasiside; Kiirem innovatsioon; Pidev parendamine; Kiire kohanemine muutustega;

Rohkem rahulolevaid kliente; Kiirendatud tempo ideest tarnimiseni.

Scrum pakub meeskonnale tööriistad, praktikad, rutiinid, tseremooniad, mis aitavad paremini protsessi mõtestada ja oma tööd organiseerida.

Ühtlasi võib metoodikat nimetada agiilseks tarkvaraarenduse metoodikaks.Scrum

7.2. Testimise metoodikad ja praktikad

Käesolevas alapeatükis käsitleme testimise temaatikat, metoodikaid ja praktikaid. Käesolevas dokumendis käsitletud mikroteenuste arhitektuuril ehitatud süsteemile tuleb rakendada kõiki vajalikke testimise metoodikaid ja testimise tüüpe, et tagada süsteemi kvaliteet ja vastavus nõuetele. Muidugi peab silmas pidama, et testimine oleks võimalikult automaatne ja kasutusel oleks tööriistad, mis hõlbustavad testide loomist ja efektiivset testimist. Süsteemi testimine on olnud palju aastaid arendajate manuaalne tegevus, millest pole jäänud jälge ja mida pole võimlaik korrata ega automatiseerida. Loodavale süsteemis tuleb kasutada testimise raamistikke ja tööriistu, mis võimaldaks teste lihtsalt kirjeldada, arendada ja korduvalt mis tahes aja hetkel käivitada.

7.2.1. Funktsionaalne testimine

Funktsionaalne testimine hõlmab rakenduste testimist ärinõuete suhtes. See kaasab mitmesuguseid testi tüüpe, et tagada, et rakenduse iga osa toimib47

nii nagu ette nähtud. Selleks kasutatakse kasutuslugusid, millised on koostanud meeskonna analüütikud ja kvaliteedi insenerid. Funktsionaalse testimise testi tüüpideks on näiteks:

Ühiktestimine (Unit test) Integratsioontestimine (Integration test) Süsteemi testimine (System test, End to End test) Vastuvõtu testimine (Acceptanse test)

Ühiktestimine on esmatasandi testimise liik, mida korraldab ja arendab tarkvara arendaja vahetult tarkvara lähtekoodi kirjutades. Testidega kaetakse väikesed koodi ühikud ja sellega veendutakse, et meetodid või funktsioonid toimivad nii nagu peavad. Ühiktestid kirjutatakse kohe samal ajal, kui põhitarkvara ja veendutakse teste käivitades, et seni arendatud tarkvara toimib vastavalt tarkvara alamosa toimimise nõuetele. Tarkvaraarenduse käigus ei tuleks üldse tarkvara ennast käivitada, vaid käivitada ainult teste, mis kontrollivad tarkvara osade tööd. Testimise andmeid loob arendaja üldjuhul ise või kasutab analüütikute või kvaliteedieksperdi poolt loodud testandmeid.

Integratsioontestimine on testimise liik mille abil testitakse juba süsteemi moodulite ja üksikute funktsioonide koostoimimist. Integratsioontestimise arendamise käigus jälgitakse samu põhimõtteid, kui ühiktestimise käigus järgiti. Selle testimise käigus võivad osaleda ja olla hõlmatud ka teised süsteemid või osapooled, mida tuleb testides, siis simuleerida. Integratsioontestid on üldjuhul nagu ka ühiktestid koodi lahutamatu osa, seega nad asuvad koodiga samas repositooriumis. Paim viis selleks on käivitada testide käivitamise ajaks ka kõik teised integratsiooni osapooled ja kasutades testandmeid vastata päringutele või täita käskluseid. Selle testimise liigi testandmed peaks olema loodud meeskonna üleselt kvaliteedieksperdi poolt.

Süsteemi testimine on testimise liik, kus testid rakendatakse süsteemi kui „musta kasti” suhtes. Nimetaud testid hõlmavad endas nii programmliidese teste kui ka kasutajaliidese teste. Üldjuhul simuleeritakse lõppkasutaja tegevusi ja testid käivitatakse päris eeltestimise keskkonnas kasutades toodangukeskkonnale ligilähedasi andmeid. Testandmestik peaks olema meeskonna üleselt hallatud ja loodud kvaliteedieksperdi poolt. Testide koostamise ja käitamise eest peaks hea seisma samuti kvaliteediekspert.

Vastuvõtutestimine on viimase funktsionaalse testimise faas ja seda kasutatakse, et kontrollida tarkvara kui terviku vastavaust ärinõuetele ja on valmis tarnimiseks toodangukeskkonda. Selle testimise käigus veendutakse, et tarkvara vastaks lõppkasutaja vajadustele. Seda testimist korraldavad ja teste arendab üldjuhul meeskonna kvaliteediekspert (automaatsed testid) ja manuaalses lõpptestimises osaleb ka lõppkasutaja esindaja. Testimine viiakse üldjuhul läbi vastuvõtutestimise või eeltoodangu keskkonnas, kasutades selleks toodangukeskkonnaga ligilähedasi andmeid.

Soovitame testimise korraldamiseks kasutada järgnevaid tööriistu ja vahendeid:

JUnit 5 48 – Java ühiktestimine ja integratsioontestimine Testcontainers49 – Integratsioontestimine, süsteemi testimine Cypress 50 - Süsteemi testimine, E2E testimine, kasutajaliidese testimine, vastuvõtutestimine WireMock51 – Integratsioontestimine, Süsteemi testimine Postman52 – tagarakenduste REST pöörduspunktide testimine

7.2.2. Mittefunktsionaalne testimine

Mittefunktsionaalne testimine peaks hõlmama tarkvara operatiivseid aspekte. Sellisteks testideks on näiteks:

Jõudlustestimine (Performance testing) Turvatestimine (Security testing) Kasutustestimine (Usability testing) Ühilduvuse testimine (Compatibility testing)

Jõudlustestimise eesmärgiks on kontrollida, kuidas rakendus käitub erinevates tingimustes ja selle käigus püütakse simuleerida reaalolukorda või koormatakse süsteemi üle planeeritud kasutuse, et leida süsteemi murdepunkt. See testimise liik jaguneb veel omakorda koormus, stress, tipu ja vastupidavuse testideks. Jõudlusteste tehakse eelkõige eeltoodangu keskkonnas suhtes, kuid on ka teisi stsenaariumeid.

Turvatestimine peab välja selgitama eelkõige, kas süsteemis käsitletavad andmed on kaitstud, süsteem on töövõimeline ja selle funktsionaalsusi poleks võimalik ära kasutada viisil, mis pole kirjeldatud ärinõuetega. Testitakse nii kasutajaliidese kaudu, kui ka pöörduspunktide kaudu. Turvatestimine tehakse eelkõige eeltoodangu keskkonnas suhtes.

Kasutustestimise eesmärgiks on kasutusmugavuse testimine lõppkasutaja vaates. Eesmärk on tuvastada, kas disain on esteetiline ja rakendus vastaks ettenähtud kasutusvoogudele. Need testid on hea viis tiimide üleselt testida mikrokasutajaliideseid ja kogu süsteemi kui tervikut.

Ühilduvustestimine võiks antud dokumendi raames kirjeldatud süsteemi osas rakendada kasutajaliidestele, et välja selgitada, kas sama kasutajaliides toimiks erinevates operatsioonisüsteemides ja Interneti sirvikute toodetes. Tagarakenduste osas sellist testimise liiki otseselt pole vajadust kohandada.

Soovitame testimise korraldamiseks kasutada järgnevaid tööriistu ja vahendeid:

Sonarqube53 – koodi staatiline analüüs, turvatestimine, koodi objektiivne kvaliteet Apache JMeter54 - jõudlustestimine

8. Koodi- ja konfiguratsiooni haldus, tehiste ehitamine, tarne Käesolevas peatükis kajastame Tarkvara lähtekoodi, rakenduste ehitamiste ja automaatsete süsteemide haldamist.

8.1. Lähtekoodi haldus, tarne ja CI/CD

Käesolevas peatükis kirjeldame detailsemalt lähtekoodi haldust, lähtekooid majutuse, tarneprotsessi, pideva integreerimise ja pideva paigaldamise temaatikat.

8.1.1. Lähtekoodi majutamine

Lähtekoodi hallatakse Git repositooriumis. Konkreetselt MKM Gitlab tarkvaraga, mis on majutatud eraldiseisvalt lõpprakendustest.

Sõltuvalt projektist tuleks kaaluda, kas monorepo, polürepo või hübriidrepo kasutamist. Monorepo on Git repositoorium, kus kõigi moodulite, teekide, mikroteenuste lähtekood on samas GIT repositooriumis. Polürepo on Git repositoorium, kus teegi, mikroteenuse või mooduli lähtekood on paigutatud eraldi repositooriumisse.

Polü- ja hübriidrepo eelduseks on, et eksisteerib tehiste repositoorium ( ), mis näiteks sisaldab kompileeritud tarkvarateeke (Java, JavaScript jne.)artifactory Repositooriumi puudumisel on nimetatud repositooriumi stiilide puhul vajalik kõik sõltuvused alati ehitamiseks alla laadida ja alati uuesti ehitada (kompileerida ja paketeerida), mis tähendab oluliselt pikemat protsessi aega.

Monorepo puhul on kõik tarkvara komponendid ühes repositooriumis. Mitmete arenduspartnerite vahel arenduste jagamisel on selline lähenemine äärmiselt ebaefektiivne tekitades arendusprotsessid administratiivset keerukust ja vajadust täpsemaks koordineerimiseks. Käeolevas dokumendis toodud mikroteenuste arhitektuuri puhul, on selline lähenemine pigem välistatud, kuna on planeeritud kaasata mitmeid arenduspartnereid ja toimuvad mitmed sama aegsed arendused.

Tulevaste arenduste puhul on võimlaik kasutada kas Gitlabi enda tehise artifaktooriumit või MKM-i artifaktooriumit Jfrog.

8.1.2. Lähtekoodi tarne haldus

Lähtekoodi tarnimiseks tuleks kasutada mõnda levinud ja hästi juurdunud lähtekoodi tarneahela protsessi (edaspidi tarneprotsess). Ühes selliseks on Goitfl . Selles tarneprotsessis on kirjeldatud, kuidas kasutada Git-i funktsionaalsuseid, harusid ( ), lipikuid (tag) jne. Selle tarneprotsessi põhiliseksow55 branch

omaduseks on järgnevad asjaolud:

„ ” harus ei toimu arendust;Main/master Jooksvad aredused asuvad harus nimetusega „ ”;develop Funktsionaalsuste arendamine toimub „ ” harudes, kus aluseks on võetud „ ”;feature develop Vastuvõtutestimine toimub haru „release” peal; Arendusharud mestitakse „ ” harusse tagasi pärast arenduse lõpetamist ja lokaalset testimist;develop „ ” haru mestitakse regulaarselt „ ” harusse, mille baasil tehakse testimist ja vastuvõtutestimist;Develop release Tarne paigaldamise järgselt mestitakse „ ” haru „ ” harusse;release master Kriitiliste ja kiireloomuliste arenduste sh. turvavigade parandamise aluseks võetakse „ ” haru ja muudatused mestitakse „ ” ja „master release develop ” harusse;

Arenduse ja tarneprotsessi osa on koodi mestimine, mis peaks toimuma kasutades Gitlabi mestimise juhtloogika ( ).merge requests

Koodi kvaliteedi tagamiseks vastavalt mestitavale koodi harule tuleb läbi viia koodi ülevaatus (code review). Samuti tuleks rakendada tarnitavale koodile staatilisi koodianalüüsi tööriistu. MKM-is on olemas staatilise koodi analüüsi tööriist, mida saab kasutada.SonarQube56

8.1.3. Lähtekoodi ehitamine ja sõltuvuste haldus

Tarkvaraprojektides on oluliseks pakettide ja sõltuvuste haldus, samuti koodi ehituse korraldamine. Eelkõige Java programmeerimiskeele maailmas, kuid mitte ainult on enamlevinud Ant, Maven ning kolmanda põlvkonna tööriistaks võiks lugeda Gradle. Soovitamegi kasutada süsteemi ehitamiseks tarkvaraprojektides Gradle tööriista ja tarkvaraprojektide paketeerimise, sõltuvuste halduse ja ehitamise tarbeks. Gradle tööriista saab kasutada nii,57

koodi genereerimise, kompileerimise, pakkide ehitamise, NPM, Node vms. Docker konteinerite loomise, käivitamise jne. tarbeks. Kui kõikides tarkvaraprojektides on üks tööriist kasutusel, siis on kogu süsteemi arendus kontrolli all ja unifitseeritud. Gradle kasutamisel kõigis tarkvara ehitamisega seotud tegevustes saab ehituskeskkonnas lihtsustada töövoogude seadistamist ja ehitusagentide unifitseerimist. Sama agendi tüübiga saab ehitada kõik tarkvarad hoolimata, kas see on Java, Node.js, vms. Tagarakendus või kasutajaliides.

8.1.4. Pidev integreerimine ja pidev tarne (CI/CD)

DevOps üheks aluspõhimõtteks on CI/CD ( ) kasutamine praktikas. Tuleb vältida manuaalseid tegevusi,Continuous Integration / Continuous Deployment mis vähendavad meeskonna läbilaskevõimet või paneb koormuse mõnele meeskonnaliikmele.

Pideva integratsiooni (CI) läbi viimiseks tuleb kasutada vastava funktsionaalsusega tarkvara. Gitlabi, mis on MKM-i ametlik Git süsteem on selline funktsionaalsus arendatud. Selleks on võimalik arendada ja konfigureerida Git repositooriumite juurde integratsiooni juhtkanalid ( ), millisedwork flows teevad ette määratud tegevusi automaatselt erinevate Git sündmuste toimumisel.

Näiteks saab käivitada automaatselt koodi ehitamist (kompileerimist ja paketeerimist) iseseisvaks teegiks ja deponeerimiseks tehiste varamusse e. artifaktooriumisse ( ) või Docker registrisse. On võimalus välja kutsuda ka CD tegevusi, mis jõustavad muudatused vajalikus keskkonnas.artifactory

Pideva paigaldamise (CD) läbiviimiseks on harilikult kasutatud juhtkanaleid ( ). Kus rakendatakse mingis majutuskeskkonnas muudatusedworkflow automaatselt. Süsteemide ja halduse keerukuse kasvamisel on mõistlik rakendada tööriistu, mis on evolutsioonis arenenud just lahendama pideva paigaldamise probleeme. Samuti võimaldab see tõsta üldist turvalisust ja detsentraliseerida protsesse. Uue põlvkonna CD põhimõtete ja tööriistade kohta kirjutame peatükis .9

8.2. Konfiguratsioonide haldus

Käesolevas peatükis käsitletakse nii süsteemi kui ka äriliste seadete ja parameetrite haldust.

8.2.1. Rakenduste ja keskkondade seaded

Rakenduste süsteemsed ja majutuskeskkondasid kirjeldavad seadeid ja parameetreid hoitakse GIT-i repositooriumis. See toimimise viis on kooskõlas DevOps ja GitOps põhimõtetega, millest on täpsemalt kirjutatud peatükis . Seadete jagamiseks on käesolevas dokumendis kirjeldatud tehnilise konfiguratsiooni moodul peatükis . Äärmiselt oluline on silmas pidida, et nimetatud seadete haldus toimuks väljaspool Kubernetes majutuskeskkonda,4.2.7 kuna on teoreetiline oht, et neid võib seal muuta, need võivad seal kaduda ja Kubernetesis seadete hoidmise korral pole tagatud seadete versioneerimine. 

8.2.2. Äriprotsessi seaded

Äriprotsessi seadeid on mõistlik hallata samuti nagu rakenduste seadeid. GIT-i repositooriumis ja jagada läbi REST teenuse. Mikroteenuste arhitektuuris on kirjeldatud tehnilise konfiguratsiooni mikroteenus peatükis . Samal viisil oleks võimalik äriprotsessi seadeid hallata ja kättesaadavaks teha teistele4.2.7 mikroteenustele. Sellisel viisil pole vaja luua andmebaasi, vastavaid protsessi mootoreid, et mingeid protsesside ja rakenduste käigus vajalikke ärilisi parameetreid hallata. Selle meetodi rakendamiseks on vaja aga muudatuste sisseviimine korraldada kahel võimalikul viisil:

a) GIT repositooriumis seadete failide muutmiseks luuakse mikroteenus ja triviaalne kasutajaliides. Seadefaili sisu kuvatakse kasutajaliideses ja muutujate muutmisel luuakse uus tekstifail. Tagarakendus kirjutab faili sisu GIT-is üle. Selline lähenemine vajab täiendavat tarkvaraarendust, kuid pole niivõrd prioriteetne. Eeliseks on asjaolu, et seadete muutja ei pea omaga otseselt GIT-i ligipääsu, ega teadmisi GIT-i repositooriumisse muudatuste tegemiseks.

b) Tavapärane GitOps protsess, kus tehakse lokaalses (lõppkasutaja tööjaamas) muudatus, viiakse muudetud failid GIT repositooriumisse ja läbitakse mestimise protsess. Selle meetodi eeliseks on, et on tagatud GitOps põhimõtte rakendamine ka äriliste muutujate puhul ja see ei vaja eraldi tarkvara arendust. Puuduseks on, et organisatsiooni lõppkasutaja peab omaga algteadmisi GitOps tööriistadest ja protseduuridest. Teisalt, kui ärilisi muudatusi tehakse DevOps raames, siis antud asjaolu ei ole miinuseks.

9. Süsteemi majutus- ja administreerimise põhimõtted Käesolevas peatükis kirjeldame dokumendis kirjeldatud mikroteenustel arendatava arhitektuuri soovituslikku maajutuse ning administreerimise põhimõtteid. Kajastame DevOps, GitOps praktikaid ja potentsiaalset majutust Riigipilves.

9.1. DevOps

DevOps lähenemine on kogum praktikatest, tööriistadest ja IT kultuurilistest filosoofiatest, mis automatiseerivad ja integreerivad tarkvaraarenduse protsesse ja IT meeskondi. See lähenemine väärtustab tiimide jõustamist, tiimide vahelist suhtlust ja kaastööd ja tehnoloogiate automatiseerimist.58

Kui vanasti olid IT meeskonnad niiöelda „silod”, kus analüütikud, arendajad ja administraatorid töötasid eraldiseisvalt ja andsid tulemeid lihtsalt üle, siis DevOps lähenemisest on need rollid põhimõtteliselt integreeritud ja nii tarkvara arendusprotsessi ettevalmistus, tarkvara arendamine, kui ka toodangusse paigaldatud tarkvara haldamine on tarkvaraarendusmeeskonna igapäevaste rutiinide osa. Kuna töömaht on kõigis nendes etappides suur, siis tuleks kõikki samme võimalikult palju automatiseerida ja protsesse standardiseerida.

DevOps elutsükkel on kujutaud joonisel 17.

Joonis 17 DevOps elutsükkel 59

DevOps-i olulisemad põhimõtted :60

Kõik meeskonna arendustegevuste tulemuste resultaat peaks olema kliendi põhine tegevus; Tarkvara on loodud lõppkasutajat silmas pidades; Meeskonnad peavad nõustuma, et neil on otsast-lõpuni vastutus kogu tarkvaratoote projekti jooksul. Edukal meeskonnal on esindatud balansseeritud oskuste komplekt, mille tulemusena on meeskond ristfunktsionaalne ja autonoomne; Eksperimenteerimine on äärmiselt vajalik, mille resultaat on väljakutsete võtmine ja pidev parendamine; IT operatsioone tuleb optimeerida ja automatiseerida kus vähegi võimalik.

9.2. GitOps

GitOps on uue põlvkonna administratiivne lähenemine. See kasutab DevOps-is tuntud tarkvara arenduse parimaid praktikaid, näiteks versioonihaldus, koostöötamine, vastavus, CI/CD ja rakendab neid infrastruktuuri, süsteemide, rakenduste administreerimisel.61

GitOps rakendamiseks tuleb jõustada lisaks DevOps lähenemisele asjaolu, et süsteemi kirjeldused ja konfiguratsioonid on hoiustatud GIT repositooriumites ja muudatuste haldus toimub läbi mestimise korralduse ( ).merge requests

GitOps tööriistaks pakume Kuberentes klastris kasutada Argo CD , mis võimaldab rakendada GitOps lähenemist. Põhimõtteskeem on kujutatud joonisel62

18.

Joonis 18. GitOps rakendamine ja Argo CD kasutamine jätkuva paigaldamise halduses

Kubernetes klastrisse on paigaldatud Argo CD operaator tarkvara, mis käib regulaarselt kontrollimas GIT seadistuste repositooriumit. Argo CD seejärel rakendab muudatused Kubernetes klastris. Argo CD kasutajaliides on ligipääsetav DevOps inseneridele ja süsteemi administraatoritele, kes saavad sellest vajalikku tagasisidet, mille abil on võimalik juhtimisotsuseid teha ja operatsioone juhtida. Käesolev lahendus tõstab ka süsteemi turvalisust, kuna pole vaja enam avada klastri administratiivset programmliidest avalikku võrku. Initsiatiiv muudatuste rakendamiseks tuleneb süsteemist seest.

9.3. Majutus Riigipilves

Süsteemi majutus peaks lähtuma põhimõttest, et kõik majutuskomponendid on välja vahetatavad ja mõistliku aja jooksul kolitavad ilma täiendavaid tarkvaraarendusi tegemata.

Erinevad teenuspakkujad võimaldavad erinevaid ärilisi probleeme lahendada omal viisil, mis tähendab, et organisatsiooni eest on ära lahendatud mingi funktsionaalsus ja tarbija saab funktsiooni kasutada sellega adapteerudes. Lühidalt on see Tarkvara nagu teenus ( ). TuleksSaaS – Software as a Service kasutada teenuseid, mille asendamine samaväärsega on lihtne ilma tarkvaras suuri muudatusi tegemata. Teisalt pakuvad majutusplatvormid platvormi teenust ( ), kus kliendile pakutakse mingit infrastruktuuri taset nt virtuaalmasin, ja klient saab sinna oma tarkvara paigaldadaPaaS – Platform as a Service ise. Käesolevas dokumendis käsitletav pilveteenus Kubernetes on Riigipilve mõttes laiendatud . Kuhu saab kliendi poolt tekitada nimeruume jaPaaS majutada erinevaid tarkvarasid üksteisest sõltumatult töötama.

Käesolev dokument on kajastanud arhitektuurses osas, milliseid teenuseid oleks mõistlik hallata tarkvara teenustena ja milliseid platvormi teenustena.

10. Kasutatud kirjandus 1 https://www.ttja.ee/

2 https://www.riigiteataja.ee/akt/125062021017?leiaKehtiv

3 https://www.ttja.ee/ariklient/ametist/ametist/tutvustus-ja-struktuur

4 Riigi infosüsteemide Amet INFOSÜSTEEMIDE KOLMEASTMELISE ETALONTURBE SÜSTEEMI ISKE, 2017

5 MSÜS, https://www.riigiteataja.ee/akt/106042021005?leiaKehtiv

6 https://www.europarl.europa.eu/news/et/headlines/priorities/digipoore/20210211STO97614/suurandmed-maaratlus-eelised-ja-voimalikud-probleemid- infograafikud

7 https://www.oracle.com/big-data/what-is-big-data/

8 https://www.oracle.com/big-data/what-is-big-data/

9 https://www.ria.ee/sites/default/files/content-editors/publikatsioonid/avaandmete_loomise_juhend.pdf

10 https://avaandmed.eesti.ee/

11 J. L. Harrington, Relational Database Design and Implementation, 4th Edition. Morgan Kaufmann, 2016, jt. 1, pt. 1, jt. 2, pt 3-5.

12 C. Chasseur, Y. Li, and J. M. Patel. Enabling json document stores in relational systems. 2013

13 https://json-schema.org/

14 https://www.riigipilv.ee/teenused/andmesalvestuse-teenus/pilw-io-storagevault-pilwio

15 https://datatracker.ietf.org/doc/html/rfc7519

16 https://www.keycloak.org/

17 https://jwt.io/

18 https://koodivaramu.eesti.ee/tehik/teis/persons-service

19 https://koodivaramu.eesti.ee/tehik/teis/payments-service

20 https://koodivaramu.eesti.ee/tehik/teis/signing-service

21 https://geoserver.org/about/

22 https://spring.io/projects/spring-cloud-config

23 https://cloud.spring.io/spring-cloud-config/multi/multi__spring_cloud_config_client.html

24 https://koodivaramu.eesti.ee/tehik/teis/signing-service

25 https://koodivaramu.eesti.ee/tehik/teis/messages-service

26 https://www.ria.ee/sites/default/files/content-editors/publikatsioonid/avaandmete_loomise_juhend.pdf

27 https://www.krakend.io/

28 https://koodivaramu.eesti.ee/tehik/teis/common-api-gateway

29 https://koodivaramu.eesti.ee/tehik/teis/xroad-gateway

30 https://redis.io/

31 https://www.elastic.co/

32 https://camunda.com/

33 https://martinfowler.com/articles/micro-frontends.html

34 https://livebook.manning.com/book/micro-frontends-in-action/chapter-1/16

35 https://redux.js.org/

36 https://zeroheight.com/3d136290e/p/188910-veera-disainissteem/b/94293b

37 https://kubernetes.io/

38 https://argo-cd.readthedocs.io/en/stable/

39 https://kubernetes.io/docs/concepts/extend-kubernetes/operator/

40 https://micrometer.io/

41 https://prometheus.io/

42 https://grafana.com/

43 https://fluentbit.io/

44 https://eits.ria.ee/et/versioon/2021/etalonturbe-kataloog/app-rakendused/app3-voorguteenused/app31-veebirakendused/1-kirjeldus/

45 https://owasp.org/www-project-application-security-verification-standard/

46 https://www.scrumalliance.org/about-scrum

47 https://smartbear.com/learn/automated-testing/software-testing-methodologies/

48 https://junit.org/junit5/docs/current/user-guide/

49 https://www.testcontainers.org/

50 https://www.cypress.io/

51 https://wiremock.org/

52 https://www.postman.com/

53 https://www.sonarqube.org/

54 https://jmeter.apache.org/

55 https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

56 https://www.sonarqube.org/

57 https://gradle.org/

58 https://www.atlassian.com/devops

59 https://www.atlassian.com/devops

60 https://www.getxray.app/blog/get-started-with-devops-principles-best-practices-and-tips?utm_term=&utm_campaign=GG_SEARCH_TOFU+- +DSA+Blog+Posts+- +EU2&utm_source=adwords&utm_medium=ppc&hsa_acc=9970092548&hsa_cam=17994277636&hsa_grp=136842240141&hsa_ad=615722725589&hsa _src=g&hsa_tgt=dsa- 1391637226778&hsa_kw=&hsa_mt=&hsa_net=adwords&hsa_ver=3&gclid=Cj0KCQjwkOqZBhDNARIsAACsbfKWamhE2aBX0hS0Y5icg5FRLGxK- 9XmngWe5O6YurKsiGWoKEGcM3caAmodEALw_wcB

61 https://about.gitlab.com/topics/gitops/

62 https://argo-cd.readthedocs.io/en/stable/

63 https://patroni.readthedocs.io/en/latest/

1

Väikehanke "Tarbijakaitse ja Tehnilise Järelevalve Ameti protsessijuhtimise ja otsustustoe

lahenduse analüüsi" pakkumuse kutse

Tarbijakaitse ja Tehnilise Järelevalve Amet (edaspidi nimetatud kui Hankija/TTJA) palub esitada

pakkumus vastavalt kutses sisalduvatele tingimustele.

Tarbijakaitse ja Tehnilise Järelevalve Ameti protsessijuhtimise ja otsustustoe lahenduse analüüs

Eelarve: 25 000 EUR (ilma käibemaksuta)

1. Pakkumuse vormistamine ja esitamine

1.1. Pakkumuses peab olema esitatud tööde kirjeldus koos ajakavaga, kuidas ülesandeid

planeeritakse lahendada ja nõutud tulemused saavutada. Projektiplaani kavandis tuleb välja

tuua tegevused, tulem(id), ajakava, vaheetapid, orienteeruv ajakulu, kuidas on hallatud riske,

tagatud tulemuste kvaliteet ja ootused Tellijale.

1.2. Pakkumuse maksumus tuleb esitada ilma käibemaksuta.

1.3. Hankija aktsepteerib elektrooniliselt esitatavate pakkumuse dokumentide osas kõiki üldlevinud

dokumendi formaate, nagu .pdf (Portable Document Format), .rtf (RichTextFormat), .odt

(Open Office) ning ka MS Office formaate.

1.4. Eelkirjeldatud nõuetele mittevastavaid, sh hilinenult esitatud pakkumusi arvesse ei võeta.

1.5. Pakkuja kannab kõik pakkumuse ettevalmistamisega ning esitamisega seotud kulud.

1.6. Hankija koostab pakkumuste hindamise kohta protokolli.

1.7. Hankija ei rakenda hankelepingu sõlmimisel ooteaega.

2. Tehniline kirjeldus

Käesoleva projekti eesmärk on analüüsida turul pakutavate protsessijuhtimise ja otsustustoe

tarkvarade sobivust TTJA ärivajadustele ning koostada detailanalüüs sobivaima lahenduse

kasutusele võtmiseks TTJA e-teenuste platvormil. Väljapakutud lahenduse alusel peab olema

võimalik alustada konkreetse lahenduse piloteerimist (sh peab olema välja selgitatud olemasoleva

e-teenuste platvormi arendusvajadus). Täpsemad tingimused on toodud Lisas 1. Protsessijuhtimise

ja otsustustoe lahenduse piloteerimiseks vajalik arendus ei kuulu käesoleva hanke skoopi.

3. Hankelepingu tingimused

3.1. Projekti algus on hiljemalt 7 päeva peale hankelepingu jõustumist.

3.2. Täpsemad lepingu tingimused sisalduvad hankelepingu projektis (Lisa 2).

4. Pakkumuste hindamine ja pakkumuse edukaks tunnistamine

4.1. Pakkumuste hindamise kriteeriumideks on pakkumuse maksumus (40%) ja analüüsi

ideelahendus (60%).

4.2. Madalaima maksumusega pakkumusele omistatakse maksimaalsed 50 väärtuspunkti. Teistele

pakkumustele omistatakse väärtuspunktid vastavalt valemile:

"40" - ("pakkumuse väärtus" - madalaim väärtus") / "suurim väärtus" * "40"

4.3. Analüüsi ideelahendust hindavad hankija hankekomisjoni liikmed eraldi. Hindamiskomisjoni

liikmete poolt omistatud väärtuspunktidest arvutatakse aritmeetiline keskmine.

Hindamiskomisjon omistab pakkuja poolt pakkumuses esitatud ideelahendile punkte

alljärgnevalt:

Väärtuspunktide

arv

Põhjendus punktide andmiseks

0 Esitatud projekt ei vasta tehnilises kirjelduses kirjeldatud nõuetele.

10 Pakkuja esitatud projekt on koostatud puudulikult või sisaldab sisulisi

vastuolusid. Hankijal ei ole arusaadav, kuidas kavatsetakse soovitud

tulemini jõuda.

2

4.4. Punktides 4.2-4.3 saavutatud punktisummad summeeritakse ja hankija tunnistab edukaks

eeltoodud kriteeriumide alusel enim väärtuspunkte kokku kogunud pakkumuse.

Hindamistäpsus on kaks kohta pärast koma.

4.5. Juhul, kui kaks või enam pakkumust on võrdsete punktisummadega, selgitatakse edukas

pakkumus välja liisuheitmise teel. Liisuheitmise korra määrab hankija. Võrdväärse pakkumuse

esitanud pakkujatel on õigus viibida liisuheitmise juures. Liisuheitmise korrast, ajast ja kohast

teavitab hankija pakkujaid e-maili teel pakkuja poolt esitatud kontaktandmetel.

Pakkumuse esitamisega kinnitab pakkuja, et ta:

 nõustub kõikide pakkumuse kutses esitatud tingimustega, sh hankelepingu projektis sätestatud

lepingu tingimustega;

 pakkumus on jõus vähemalt 30 päeva pakkumuste esitamise tähtpäevast arvates.

Hankija kontaktisik, kes jagab selgitusi hankega seotud küsimustes, on Arthur Allas,

[email protected], telefon 620 1757. Hankijal ei ole kohustust vastata hankega seotud küsimustele,

mis on esitatud hiljem kui 2 tööpäeva enne pakkumuste esitamise tähtaja saabumist.

Pakkumuse palume esitada hiljemalt 26.01.2024 kl 12.00 e-posti aadressile [email protected].

TTJA jätab endale õiguse lükata tagasi kõik esitatud pakkumused sõltumata põhjus(t)est.

Lisad

Lisa 1 – Tehniline kirjeldus

Lisa 2 – Hankelepingu projekt

Lisa 3 - Arhitektuur Lisa 4 - TTJA standardiseeritud loataotluse protsess (protsessi joonis) Lisa 5 - Majandustegevusteate taotluse esitamise protsess (protsessi joonis)

20 Pakkuja esitatud projektist ei ole selgelt aru saada, kuidas hanke

alusdokumentides kirjeldatud nõuded, ootused tulemusele ning

eesmärkidele planeeritakse realiseerida. Kõik tööd ei ole jaotatud

etappideks või ei ole nende etappideks jaotamine selgelt põhjendatud või

põhjendused arusaadavad või ei ole etappide mahuhinnangud realistlikud

arvestades etapi tulemite mahtu ja keerukust. Projektis esineb olulisi

puudujääke. Hankija hinnangul ei pruugi pakkuja pakkuda sobivat

lahendust.

40 Pakkuja on aru saanud probleemi olemusest ning projekt on esitatud

struktureeritult ja põhjendatult. Esitatud projektis on arusaadavalt

kirjeldatud, kuidas alusdokumentide nõuded, ootused tulemusele ning

eesmärkidele planeeritakse realiseerida. Projekt on läbimõeldud ning

enamalt jaolt sobivad Tellija teenuste portfelli, kuid esinevad üksikud

puudujäägid, vastuolud ja/või ebatäpsused, kuid need ei ole oluliseks

takistuseks.

60 Pakkuja on täielikult aru saanud probleemi olemusest ja

ülesandepüstitusest. Projekti eesmärgi saavutamiseks vajalikud tegevused

on loogilises järjestuses ja omavahelises seoses. Projektis esitatud

tegevused on jaotatud läbiviimiseks sobiva kestusega etappideks, etapi

tööde mahuhinnangud on realistlikud arvestades etapi tulemite mahtu ja

keerukust. Projekt on põhjalik, läbimõeldud ja ammendav ning täies

mahus sobivad Tellija teenuste portfelli vajadustele.

1 / 16

“Protsessijuhtimise ja otsustustoe lahenduse

analüüs”

Projektiplaan ja tööde kirjeldus

Tellija: Dokumendi kuupäev: Dokumendi autorid:

Tarbijakaitse ja Tehnilise Järelevalve Amet

29.01.2024 Rait Raidma, Kertrud Järg

2 / 16

Sisukord

Sisukord ........................................................................................................................................................... 2

Sissejuhatus ..................................................................................................................................................... 3

Mõisted ja lühendid ..................................................................................................................................... 3

Kolm analüüsitavat tarkvara ............................................................................................................................ 4

Tööde kirjeldus ................................................................................................................................................ 5

Esimene etapp - eelanalüüs ......................................................................................................................... 5

Teine etapp - detailanalüüs ......................................................................................................................... 9

Tulemuste kvaliteedi tagamine .....................................................................................................................13

Riskid ..............................................................................................................................................................14

Projekti ajavaka ja maksumus .......................................................................................................................15

Tööde teostamiseks vajalikud rollid ja hinnangulised mahud ...................................................................15

Pakkumuse maksumus ..............................................................................................................................15

Projektiplaan ..............................................................................................................................................15

3 / 16

Sissejuhatus

TTJA-l on 2 infosüsteemi - JVIS (Järelevalve Infosüsteem) ja MTR (Majandustegevuse Register).

Pakkumuse koostamise hetkel on arenduses uue TTJA e-teenuste platvormi esimeste komponentide

arendus, mille raames võimaldatakse esitada 10 erinevat majandustegevusteadet. Uue e-teenuste

platvormi lõpp-eesmärk on välja vahetada vanad süsteemid.

Vanades süsteemides on teenuseomanikel olnud puudu võimalus mõõta teenuse osutamist, hinnata

efektiivsust ning tuvastada teenusprotsesside pudelikaelu ja automatiseerimisvõimalusi. Antud

puudujääki soovitakse uue e-teenuste platvormiga kõrvaldada.

Käesoleva hanke projekti eesmärk on analüüsida turul olemasolevate protsessijuhtimise ja otsustustoe

tarkvarade sobivust TTJA loodava e-teenuste platvormile ning koostada detailanalüüs kõige

sobivama lahenduse kasutusele võtmiseks. Detailanalüüsi alusel peab olema TTJA-l võimalik tellida

antud tarkvara integreerimise arendust.

Antud dokumendi eesmärk on esitada Pakkuja poolne nägemus, millist 3 alternatiivset tarkvara

plaanitakse analüüsida eelanalüüsi käigus, projekti jooksul tehtavatest tegevustest, vaheetappidest,

riskide haldamisest, tulemuse kvaliteedi tagamisest, ootustest Hankijale ning tulemitest.

Mõisted ja lühendid

Mõiste Selgitus

JVIS Järelevalve Infosüsteem

KeMIT Keskkonnaministeeriumi Infotehnoloogiakeskus

MoSCoW meetod Meetod, mille abil prioriseeritakse nõudeid (Peab olema/Must have; Peaks

olema/Should have; Võib olla/Could have; Ei pea olema/Will not have)

MTR Majandustegevuse Register

TTJA Tarbijakaitse ja Tehnilise Järelevalve Amet

4 / 16

Kolm analüüsitavat tarkvara

Käesoleva projekti raames analüüsitakse 3 alternatiivset protsessijuhtimise ja otsustustoe tarkvara,

milleks on:

• Camunda - https://camunda.com/

• JBPM - https://www.jbpm.org/

• Flowable - https://www.flowable.com

Need tarkvaralahendused on valitud järgmistel põhjustel:

• Nad säilitavad põhjalikku ajalugu, võimaldades pärida, analüüsida ja jälgida protsessi

instantside kulgu, hetkeseisu, koguarvu ja käivitusaega.

• Võimaldavad lihtsasti luua uusi protsessi instantse ja hallata nende olekuid, parameetreid ja

samme.

• Säilitavad protsesside varasemaid versioone, tagades sellega parema jälgitavuse.

• Pakuvad võimekaid protsesside modelleerimise tööriistu, mille abil saab luua protsessi

diagramme (BPMN).

• Toetavad ärireeglite (DMN) kirjeldamist.

• On arendatud Java keskkonnas ning neid saab tarnida nii eraldiseisvalt kui ka rakendusse

põimitult (embedded).

• Toetavad mitmesuguseid andmebaasisüsteeme, tagades maksimaalse ühilduvuse.

• On laiendatavad, võimaldades kohandada vastavalt vajadustele.

• Varustatud API-dega, mis võimaldavad kõigi protsessidega seotud andmete hõlpsat pärimist,

võimaldades vajadusel arendada juurde täiendavat funktsionaalsust.

• Omavad turul pikaajalist kohalolu, pakkudes usaldusväärset tuge.

• Pakuvad kvaliteetset dokumentatsiooni koos näidetega, muutes nende kasutamise lihtsaks ja

arusaadavaks.

• Omavad suurt kasutajaskonda ja on populaarsed tänu nende aktiivsele arendusele.

5 / 16

Tööde kirjeldus

Käesolevas peatükis annab Pakkuja ülevaate projekti raames tehtavatest tegevustest, et saavutada

projekti tulemid. Projekti tulemi alusel peab olema võimalik TTJA-l tellida protsessijuhtimise

lahenduse integreerimise arendust.

Projekt koosneb kahest etapist - eelanalüüs ja detailanalüüs. Järgnevalt on kirjeldatud töö mõlema

etapi teostamise plaan ja tegevused, kuidas nõutud tulemini plaanitakse jõuda.

Kokkuvõtvalt, koosneb kogu projekti tulem:

• Vahearuanne, mille tulemuseks on 3 protsessijuhtimise tarkvara lahenduse võrdlemine ning

ühe välja valimine millele koostatakse detailanalüüs

• Lõpparuanne, mille tulemusena on TTJA-l võimalik välja valitud lahenduse integreerimise

arendust

Esimene etapp - eelanalüüs

Töö esimese etapi käigus viiakse läbi eelanalüüs, kus selgitatakse välja täpsemad funktsionaalsed

nõuded ja vajadused, mille käigus arvestatakse, et väljapakutav lahendus sobib loodava e-

teenuste platvormiga ja sinna loodavate ja juba olemasolevate komponentidega. Eelanalüüsi

tulemina hinnatakse ja valitakse välja, koostöös Hankijaga, kolme alternatiivi seast sobivaim

arvestades asjaoluga, et lahenduse kasutajateks saab nii IT-haridust omavad isikud kui ka kasutajad,

kellel puudub vastav ettevalmistus.

Eelanalüüsi etapi tegevused jagunevad:

1. Ettevalmistus

2. Funktsionaalsete nõuete ja vajaduste täpsustamine, sh:

a. Intervjuude läbiviimine Hankija poolsete kasutajatega (nii tehniliste kui ka äri

kasutajatega)

b. Nõuete prioriseerimine

c. Olemasolevate komponentidega tutvumine ja valmiduse tuvastamine (sisaldab

koosolekuid Hankijapoolse arenduspartneriga)

3. Alternatiivide võrdlemine, sh sobivaima lahenduse pakkumine, sh:

a. Kolme alternatiivi katsetamine

b. Võrdlusmaatriksi loomine

4. Vahearuande koostamine ja kooskõlastamine

Läbi erinevate tegevuste korraldatakse jooksvalt koosolekuid Hankijaga, et arutada võimalikke

tekkinud küsimusi ja hoida Hankijat kursis töö edasiminekuga. Kõik koosolekud protokollitakse

Pakkuja poolt ning tehakse kättesaadavaks projekti Confluence-is.

Järgnevalt on kirjeldatud eelanalüüsi etapis vajatav sisend, ootused Hankijale ning detailsemalt iga

tegevus, mis on plaanitud antud etapi tulemite saavutamiseks.

6 / 16

Vajatav sisend

Eelanalüüsi etapi edukaks läbiviimiseks vajatav sisend on järgmine:

• Hankija ja nende kontaktide nimekiri

• Intervjueeritavate ja nende kontaktide nimekiri

• Ligipääs olemasolevatele komponentide lähtekoodile

• Hankijapoolse arendaja kontaktide nimekiri

• Vajatavad ligipääsud ja volitused

• Vajatavad alusmaterjalid

• Kohtumiste protokollide formaadi näidis (olemasolu korral)

• Vahearuande formaadi näidis (olemasolu korral)

Ootused Hankijale töö esimeses etapis

Eelanalüüsi etapis on ootused Hankijale järgmised:

• Edastab Pakkujale vajalikud kontaktid intervjuude läbiviimiseks

• Edastab vajalikud alusmaterjalid ja ligipääsud

• Edastab vajalikud ja olemasolevad dokumentide formaadi näidised

• Vaatab üle ja annab tagasisidet jooksvalt tegevuste tulemite üle

• Osaleb projekti koosolekutel

• On kättesaadav küsimuste tekkimisel

Ettevalmistus

Selleks, et koostöö sujuks, kõikidel osapooltel oleks selge, mis on ootused ja projekt oleks edukas,

on oluline lühike ettevalmistusperiood, mille jooksul:

• Tutvutakse töögrupiga ning määratakse rollid

• Lepitakse kokku tööprotsessides ja tööinstrumentides

• Saadakse ligipääsud olemasolevatele sisendmaterjalidele, dokumentidele ja vajalikele

süsteemidele

• Tutvutakse sisendmaterjalidega

Antud tegevuste läbiviimiseks korraldatakse vajadusel koosolekud näiteks videosilla vahendusel või,

sõltuvalt olukorrast, füüsiliselt. Tehtud tegevuste tulemiks on projekti läbiviimise plaan, mis loob

head eeldused edukaks projektiks.

Funktsionaalsete nõuete ja vajaduste täpsustamine

Eelanalüüsi etapi esimeseks sisuliseks tegevuseks on funktsionaalsete nõuete ja vajaduste

täpsustamine. Antud tegevuse aluseks võetakse:

• Hanke tehnilises kirjelduses loetletud ootused ja vajadused

• Tehnilised nõuded, mille sätestab TTJA e-teenuste platvormi arhitektuur

7 / 16

• KeMIT-i mittefunktsionaalsed nõuded

Nõuete ja vajaduste täpsustamise raames viiakse läbi järgmised tegevused:

1. Viiakse läbi intervjuud nii uue lahenduse tehniliste kui ka äriliste kasutajatega

2. Prioriseeritakse selgunud nõuded ja vajadused

Intervjuude läbiviimine

Intervjuud kasutajatega teostatakse üle videosilla ning intervjuud dokumenteeritakse projekti

Confluence-is. Intervjuude jooksul kasutatakse metoodikat, mis jaguneb kahte etappi:

1. Avasta

2. Defineeri

Esimese etapi fookus on koguda kasutajatelt võimalikult palju sisendit nende ootuste, soovide,

probleemide ja vajaduste kohta.

Teise etapi fookus on analüüsida kogutud infot, et mõista ja kaardistada väärtuslik sisend. Selle abil

on võimalik täpsemalt defineerida kõige olulisemad vajadused ja soovid seoses integreeritava

lahendusega.

Loetletud kahte etappi on võimalik itereerida kuniks on käes piisaval hulgal infot.

Nõuete prioriseerimine

Kui nõuete loetelu on olemas ning on piisaval hulgal infot, seatakse nõuded koostöös Hankijaga

prioriteetide järjekorda. Selle tegevuse eesmärgiks on tuvastada integreeritava lahenduse kõige

olulisemad nõuded, et veenduda, et valitav lahendus kataks kõige olulisema.

Nõuete prioriseerimisel kasutatakse MoSCoW meetodit. Antud meetodiga jaotatakse kõik nõuded ja

vajadused järgmistesse kategooriatesse:

• Peab olema (Must have). Kõige kriitilisemad nõuded, mis on integreeritava lahenduse puhul

kohustuslikud. Nende nõuete täitmata jätmisel ei ole võimalik lahendust integreerida loodava

e-teenuste platvormiga

• Peaks olema (Should have). Nõuded, mis on olulised, kuid mitte nii kriitilised. Nõuded, mis

aitavad oluliselt kaasa lahenduse funktsionaalsusele ja kasutatavusele

• Võib olla (Could have). Nõuded, mis on soovitatavad, kuid ei ole hädavajalikud. Nõudeid

võib kaaluda, kui lahendus ning arendusaeg ja –ressursid seda võimaldavad peale olulisemate

nõuete täitmist

• Ei pea olema (Will not have). Nõuded, mis ei ole olulised antud lahenduse integreerimise

aspektist ja millega ei arvestata lahenduse valikul

Väljapakutud nõuete prioriseerimine tehakse koostöös Hankijaga, mille jaoks Pakkuja viib läbi

töötoa, mille tulem dokumenteeritakse projekti Confluence-is. Nõuete lõplik, prioriseeritud nimekiri

kinnitatakse Hankija poolt.

8 / 16

Alternatiivide võrdlemine

Alternatiivide võrdlemisel võetakse aluseks eelmise tegevuse raames loodud nõuete ja nende

prioriteetide nimekiri. Analüüsitakse Pakkuja poolt välja pakutud kolme erinevat protsessijuhtimise

ja otsustustoe tarkvara lahendust, mille võrdlemisel hinnatakse järgmiseid aspekte:

• Lahenduse sobivus TTJA nõuetega, sh

o Täidetud peavad olema kõik nõuded, mis on kategoorias “Peab olema”

o Täidetud peab olema suur osa nõuetest, mis on kategoorias “Peaks olema”

o Nõuded, mis on kategooriates “Võib olla” ja “Ei pea olema” ei ole lahenduse valikul

kriitilised

• Lahenduse kasutusmugavus, tugi ja koolitusvõimalused nii tehnilisele- kui ka ärikasutajale

• Lahenduse integratsiooni võimalused ja ühilduvus

• Lahenduse funktsionaalsused ja võimalused (protsesside loomisel, muutmisel, kustutamisel,

jne)

• Lahenduse skaleeritavus ja jõudlus, sh arvestades mahu kasvuga

• Lahenduse paindlikkus

• Lahenduse kasutuselevõtmise prognoositav kulu

• Lahenduse kasutuselevõtmisel prognoositav ajakulu selle juurutamisel (k.a eelduslikud

rollid)

• Lahenduse kasutuselevõtmisega kaasnevad riskid ja maandamismeetmed

• Lahenduse kasutamise prognoositavad püsikulud (5-aastase ajaperioodi jooksul)

• Lahenduse integratsioonivõimalused arendusjärgus ja olemas olevate TTJA e-teenuste

platvormi tehniliste lahendustega

Kuigi võetakse aluseks Pakkuja poolt pakutud kolm alternatiivi, siis lõplik analüüsitavate

lahenduste valik lepitakse kokku Pakkujaga. Alternatiivide võrdlemiseks luuakse tabel, mis on

kättesaadav projekti Confluence-is, kuhu koondatakse kokku kogu informatsioon, mis on oluline

selleks, et valida lahendus, millega loodav e-teenuste platvorm integreeritakse.

Antud tegevuse lõpus esitab Pakkuja omapoolse hinnangu, milline lahendus on vastavalt analüüsitud

aspektidele kõige mõistlikum ja optimaalsem integreerida.

Vahearuande koostamine ja kooskõlastamine

Antud tegevuse käigus koondatakse kokku kõik eelanalüüsi etapi raames kogutud informatsioon koos

tulemitega. Vahearuanne seejärel kooskõlastatakse Hankijaga ning vajadusel tehakse vastavad

muudatused.

Kokkuvõtvalt sisaldab vahearuanne järgmiseid osi:

1. Ülevaade läbiviidud intervjuudest ja olulisemad taipamised

2. Lõplik nõuete ja vajaduste nimekiri, sh prioriteetide kategooriad

3. Analüüsitavate lahenduste võrdlustabel

4. Pakkuja poolne soovitus lahenduse valikul

9 / 16

Vahearuande tulemusel valib Hankija eelanalüüsitud lahendustest endale kõige sobivama.

Antud eelanalüüsi etapi tulem on eelduseks ja sisendiks projekti teise etapi jooksul tehtavale tööle.

Teise etapi tööd on kirjeldatud järgmistes peatükkides.

Teine etapp - detailanalüüs

Töö teise etapi käigus viiakse läbi detailanalüüs, kus analüüsitakse eelmise etapi tulemina välja

valitud protsessijuhtimise ja otsustustoe tarkvara integreerimist loodava TTJA e-teenuste

platvormiga. Loodava detailanalüüsi põhjal on Hankijal võimalik tellida antud lahenduse kasutusele

võtmiseks vajalikud arendustööd. Kogu detailanalüüsi jooksul arvestatakse TTJA e-teenuste

platvormi arhitektuuriga ja selle tehniliste nõuetega ning KeMIT-i mittefunktsionaalsete

nõuetega.

Detailanalüüsi etapi tegevused jagunevad:

1. Funktsionaalse spetsifikatsiooni loomine, sh

a. Liideste kirjeldamine

b. Andmemudelite kirjeldamine

c. Tööriista üldiste kasutuslugude, protsesside kirjeldamine koos protsessijoonistega

2. IT arhitektuuri loomine, sh arvestades arhitektuurile seatud nõuetega

3. IT infrastruktuuri vajaduste kaardistamine

4. Detailse arenduskava loomine lahenduse realiseerimiseks, sh

a. E-teenuste platvormi jätkuarenduste kava

b. Liidestuse välja arendamiseks vajaminevate arenduste kava

5. Viieaastase püsikulude prognoosi arvestuse esitamine

6. Lõpparuande koostamine ja kooskõlastamine

Läbi erinevate tegevuste korraldatakse jooksvalt koosolekuid Hankijaga, et arutada võimalikke

tekkinud küsimusi ja hoida Hankijat kursis töö edasiminekuga. Kõik koosolekud protokollitakse

Pakkuja poolt ning tehakse kättesaadavaks projekti Confluence-is.

Järgnevalt on kirjeldatud detailanalüüsi etapis vajatav sisend, ootused Hankijale ning detailsemalt iga

tegevus, mis on plaanitud antud etapi tulemite saavutamiseks.

Vajatav sisend

Detailanalüüsi etapi edukaks läbiviimiseks vajatav sisend on järgmine:

• Tehniliste kontaktide nimekiri, sh Hankijapoolse arendaja kontaktid

• Ligipääs olemas olevatele komponentide lähtekoodile

• Vajatavad ligipääsud ja volitused

• Vajatavad alusmaterjalid

• Vahearuande tulem

• Lõpparuande formaadi näidis (olemasolu korral)

10 / 16

Ootused Hankijale töö teises etapis

Detailanalüüsi etapis on ootused Hankijale järgmised:

• Edastab Pakkujale vajalikud tehnilised kontaktid, kellega vajadusel kontakteeruda

• Edastab vajalikud alusmaterjalid ja ligipääsud

• Edastab vajalikud ja olemasolevad dokumentide formaadi näidised

• Vaatab üle ja annab tagasisidet jooksvalt tegevuste tulemite üle

• Osaleb projekti koosolekutel

• On kättesaadav küsimuste tekkimisel

Funktsionaalse spetsifikatsiooni loomine

Hanke raames läbiviidava töö teise etapi esimese sisulise tegevuse raames luuakse liidestuse

funktsionaalne spetsifikatsioon, sh:

• Tööriista üldiste kasutuslugude ning protsesside kirjeldus koos vajalike joonistega

• Liidestuste kirjeldused

• Andmemudelite kirjeldused

• Muud funktsionaalsuse poolest olulised aspektid, mille dokumenteerimise vajadus

detailanalüüsi jooksul selgub

Funktsionaalse spetsifikatsiooni loomisel on olulised regulaarsed koosolekud Hankijaga, et

veenduda töö progressis ning saada pidevat tagasisidet, et jooksvalt teha spetsifikatsioonis

muudatusi. Kogu spetsifikatsioon ning koosolekute memod on Hankijale kättesaadav jooksvalt

projekti Confluence-is.

IT arhitektuuri loomine

IT arhitektuuri loomisel võetakse aluseks loodava e-teenuste platvormi arhitektuur ning KeMIT-i

sätestatud mittefunktsionaalsed nõuded. Arhitektuuri väljatöötamisel kirjeldatakse järgmised osad:

• Süsteemide kirjeldus

• Integreerimiseks vajaminevad komponendid ja moodulid, sh

o E-teenuste platvormi komponendid ja moodulid

o Välja valitud lahenduse komponendid ja moodulid

• Komponentide omavaheline suhtlus ja protokollid

Vajadusel viiakse läbi ka tehnilisi kohtumisi TTJA poolse tehnilise inimesega, et veenduda, et loodav

arhitektuur vastab vajadustele ning ei jää märkamata olulised aspektid.

11 / 16

IT infrastruktuuri vajaduste kaardistamine

Infrastruktuuri vajaduste all kirjeldatakse ära, millised ressursid tuleb arhitektuuris välja

pakutud komponentidele eraldada, et saavutada piisav võimekus ette nähtud töövoogude

töötlemiseks:

• Kõvaketta tüüp ja maht

• Mälumaht (RAM)

• Protsessor (CPU)

Selleks tehakse koormustestid kasutades olemas olevaid mahuhinnanguid.

Detailse arenduskava loomine lahenduse realiseerimiseks

Kui funktsionaalse spetsifikatsioon ja arhitektuur ning infrastruktuur on paigas, on võimalik välja

töötada detailne arenduskava. Arenduskava loomisel selgitatakse välja:

1. Protsesside juhtimise tarkvaraga liidestumiseks vajaminevad arendustegevused loodava e-

teenuste platvormi poolel

2. Protsesside juhtimise tarkvara kasutuselevõtuga seotud arendused (liidestamisega seotud

arendused, oluliste nõuete täitmiseks vajalikud arendused)

3. Jätkuarenduste kava

Esimesel arendusvajaduste ja –tegevuste kaardistamisel selgitatakse välja tegevused e-teenuste

platvormi poolel, mis on vajalikud selleks, et platvorm oleks protsesside juhtimise tarkvaraga

liidestamiseks valmis. Selleks võetakse aluseks majandustegevusteate esitamise protsess, sest

esimeste majandustegevusteadete e-teenuste platvormile üle toomise käigus on võimalik piloteerida

liidestust.

Protsesside juhtimise tarkvara kasutuselevõtuga seotud arenduste kaardistamise puhul tuvastatakse

kõik arendustegevused, mis on vajalik selleks, et loodav e-teenuste platvorm integreerida välja valitud

tarkvaraga. Siin võetakse samuti aluseks majandustegevusteate esitamise protsess, millega

piloteeritakse liidestust.

Jätkuarenduste kava väljatöötamisel võetakse aluseks kogu loateenuse protsess. Loateenuse

protsess on keerulisem, sest see hõlmab endas avalduste menetlemist ning tulevikus on ka need

teenused plaanis üle tuua uuele e-teenuste platvormile. Jätkuarenduste kavas tuuakse välja selle

jaoks vajalikud arendused e-teenuste platvormi poolel ning ka liidestuse edasiarendusega

seotud arendustegevused, mis selguvad detailanalüüsi jooksul.

Iga arendustegevuse puhul hinnatakse selle ligikaudne aja- ja hinnakulu, mis aitab TTJA-l edasiste

arendustellimuste puhul ressursse planeerida.

12 / 16

Viieaastase püsikulude prognoosi arvestuse esitamine

Viimase sisulise tegevusena antakse ülevaade lahenduse viieaastase püsikulude prognoosist. Selle

esitamisel lähtutakse tootjapoolsetest suunistest ja lahenduse eripärast. Prognoos sisaldab nii e-

teenuste platvormi poolseid kui liidestuse ülalpidamise kulusid, sh:

• Majutuskulud

• Litsentsikulud

• Hoolduskulud

• Tööjõukulud koos eeldatavate rollidega

Prognoos esitatakse tabelina, mis on kättesaadav projekti Confluence-is ja mida saab võtta aluseks

arendustööde tellimiseks.

Lõpparuande koostamine ja kooskõlastamine

Antud tegevuse käigus koondatakse kokku kõik detailanalüüsi etapi raames kogutud informatsioon

koos tulemitega. Lõpparuanne kooskõlastatakse Hankijaga ning vajadusel tehakse vastavad

muudatused ja korrektuurid.

Kokkuvõtvalt sisaldab lõpparuanne järgmisi osi:

1. Liidestuse ja lahenduse funktsionaalne spetsifikatsioon

2. IT arhitektuuri kirjeldus

3. IT infrastruktuuri kirjeldus

4. Detailne arenduskava koos arendusmahtudega

5. Viieaastane püsikulude prognoos

Lõpparuande tulemusel on võimalik Hankijal tellida lahenduse integreerimiseks vajalik

arendustöö ning planeerida edasisi ressursse ja jätkuarendusi.

13 / 16

Tulemuste kvaliteedi tagamine

Kogu projekti vältel plaanitakse kvaliteeti tagada järgmistel meetoditel:

• Pädevate rollide olemasolu. Projektis on kaetud tehniline pool arhitekti poolt ning äriline

pool analüütiku poolt, mis tagab selle, et kõiki analüüsi aspekte on silmas peetud.

• Kokkulepete loomine ja regulaarsed koosolekud. Projekti ettevalmistus sammus tehakse

vajalikud kokkulepped ja jaotatakse rollid, mis on projekti edukaks olemise eelduseks. Lisaks

kogu projekti vältel tehakse regulaarseid koosolekuid, kus Hankija saab ülevaate tehtud

töödest ja anda jooksvalt tagasisidet, mida saab võtta kohe arvesse.

• Nelja silma kontroll. Projektis osalevad inimesed on kursis teiste liikmete tehtavate töödega

ning kontrollivad üksteise töid, veendumaks et töö kõik osad oleksid loogilised ja sobivad

omavahel kokku ning et ükski oluline aspekt ei puuduks analüüsist.

14 / 16

Riskid

Kirjeldus Tõenäosus Mõju Maandamine

Analüüs nõuab suhtlust

erinevate osapooltega ja

rollidega, millega võib

kaasneda erinevate osapoolte

ressursside puudus, erinevate

nägemuste kooskõlastamine,

jne.

Keskmine Keskmine • Alustades koostööd, rollide

ja suhtluse korra määramine

• Info aegsasti vahetamine ja

õigel ajal kontakti leidmine

• Tegevuste ette planeerimine

Nõudeid on potentsiaalselt

väga palju, ei leidu sellist

tarkvara, mis kõiki nõudeid

katab

Keskmine Suur • Nõuete

prioriseerimine(MoSCoW

meetod)

• Prioriteetide

kooskõlastamine erinevate

osapoolte vahel, et saavutada

ühine nägemus

Analüüsi tulem ei vasta

nõuetele ning tulemit peab

pidevalt korrigeerima, mis

ohustab projekti õigeaegset

valmimist

Keskmine/Madal Suur • Aegsasti osapooltele info

edastamine

• Pidevad koosolekud

Hankijaga, et saada tööle

jooksvat tagasisidet

• Hankija poolt aegsasti töö

tagasisidestamine

Ei saa ligipääse vajalikele

andmetele

Madal Keskmine • Hankija poolel on

konkreetne isik, kes vastutab

selle eest, et Pakkuja saab

ligi vajalikele dokumentidele

ning koodile

• Lähtume nendest andmetest,

mis on kättesaadavad

15 / 16

Projekti ajavaka ja maksumus

Tööde teostamiseks vajalikud rollid ja hinnangulised mahud

Käesolevas peatükis on esitatud kogu analüüsiprojekti läbiviimiseks vajalikud tegevused ja etapid

koos nende hinnanguliste mahtudega. Mahuhinnangud on esitatud päevades.

Tegevus Analüütik (p) Arhitekt (p) Kokku (p)

Eelanalüüs

Ettevalmistus 2 1 3

Funktsionaalsete nõuete ja vajaduste kaardistamine 4 1 5

Alternatiivide võrdlemine 0,5 9 9,5

Vahearuande koostamine ja kooskõlastamine 2 1 3

Detailanalüüs

Funktsionaalse spetsifikatsiooni loomine 10 2 12

IT arhitektuuri loomine 0,5 4 4,5

IT infrastruktuuri kaardistamine 0,5 4 4,5

Detailse arenduskava loomine lahenduse

realiseerimiseks

1 4 5

Viie aasta püsikulude prognoosi arvestuse esitamine 0,5 1 1,5

Lõpparuande koostamine ja kooskõlastamine 4 1 5

Kokku (p): 53

Pakkumuse maksumus

Töö nimetus Maksumus, KM-ta Maksumus, KM-ga

Eelanalüüs 9 724,00 € 11 863,28 €

Detailanalüüs 14 908,00 € 18 187,76 €

Kokku: 24 632,00 € 30 051,04 €

Projektiplaan

Järgneval joonisel on kujutatud esialgne projektiplaan. Projektiplaani koostades on arvestatud, et

mõndasid tegevusi saavad projektiliikmed paralleelselt teha.

Tööde alguses projektiplaan täpsustub ning võib muutuda kooskõlastatult Hankijaga vastavalt

projekti tegelikule algusajale. Projekti eelduslikuks algusajaks on arvestatud 19.02.2024 ning tööde

lõpptähtajaks oleme arvestanud 19.04.2024. Vastavalt projekti nõuetele oleme arvestanud eelanalüüsi

perioodiks 19.02.2024-08.03.2024 ning detailanalüüsi perioodiks 11.03.2024-19.04.2024.

16 / 16