code

Loeng 2 · Infosüsteemide üldised omadused ja tüpoloogia

• Talunik tarbija otseturundus
• Mille poolest veebirakendus erineb veebilehest? “What is Open Web App, technically?”
• Mis on virtuaalmasin? Mis on hüperviisor? NIST Security Recommendations for Hypervisor Deployment
• “On mobile, each app can only focus on doing one thing well.” M. Zukerberg Facebook Messengerist
• Elektroonilise identiteedi (eID) tarkvara laiendamine mobiilsetele platvormidele

Vt ka infosüsteemide näiteid.

Ettevõtte IT-portfell. Organisatsioonis kasutatakse tavaliselt paljusid erinevaid infotehnoloogiaid. Organisatsioon tihti ei oma selget ülevaadet oma tehnoloogiakasutusest. Selline ülevaade on aga ettevõtte IT juhtimiseks ja optimeerimiseks hädavajalik.

Artikli TL;TR

Carter, M & Grover, V (2015) Me, my self, and I(T): conceptualizing information technology identity and its implications. MIS Quarterly.

Intrigeeriv teooria sellest, et arvutikasutus, “netisolek” on tasapisi muutunud inimese identiteedi (enesepildi) lahutamatuks osaks (kasutan Facebooki, järelikult olen)

Tehnoloogiate kombineerimine e kooskasutamine on süsteemide ehitamisel hädavajalik.

Tehnoloogiapinu (Technology Stack) on protsessi, lahenduse või keskkonna loomiseks väljavalitud tehnoloogiate (või tehnoloogiaid teostavate tööriistade, tarkvararakenduste või teenuste) kogum. Tehnoloogiapinus olevad tehnoloogiad peavad üksteisega “rääkima”, moodustama toimiva, efektiivse ja väärtustloova terviku. Pinu kujundamine võib olla keerukas, strateegilise kaaluga otsus.

Näide

Uber techstack

Näide

MEAN, “an opinionated fullstack javascript framework” koosneb 4 osatehnoloogiast: MongoDB, Express, AngularJS, Node.js; LAMP, populaarne veebiarenduspinu: Linux, Apache HTTP server, MySQL, PHP.

Näide

Käesoleva väikese veebisaidi tegemisel on kasutatud oma 15 erinevat töövahendit ja tehnoloogiat:

• Markdown - laialtlevinud märgendkeel
• GitHub - versioonihaldustarkvara
• Git Bash - Git versioonihalduse tööriist
• Jekyll - staatilise veebisaidi generaatorrakendus
• Kramdown - Jekylli preprotsessor (eeltöötleja)
• HTML5 - universaalne veebikeel
• CSS3 - veebi kujunduskeel
• Sass
• Liquid - templiidikeel
• YAML - lihtne märgendkeel
• Visual Studio Code - programmeerija tekstiredaktor
• asciiFlow - lihtne jooniste redaktor
• Google Material Design ikoonid
• Google Fonts

Täiendada tuleks veel mitmega:

• eesti keele õigekirja kontrollija (head lahendust ei ole)
• skript statistika arvutamiseks (Python?)
• veebianalüütika (Google Analytics)

Näide

Riigiasutuses IT-profiil (RIK)

In­fo­süs­tee­mi on otstarbekas määratleda kui süs­teem­set teh­no­loo­gi­list lahendust organi­sat­si­ooni info­käit­lus­prob­lee­mi­le (või prob­lee­mi­de­le).

Süsteemi iseloomustab tulemuslikkus, efektiivsus Ilm­selt seda, et tegevus on tule­mus­lik ja samal ajal öko­noom­ne, ele­men­did töö­ta­vad hästi kok­ku. Üldise süs­tee­mi­te­oo­ria (General Sys­t­ems Theory) kohaselt koosneb ko­gu maa­ilm süsteemidest. Kuid meie käsitus süs­tee­mist on kit­sam. Süs­teem ei ole mitte iga­sugune ele­men­ti­dest kui­da­gi­moodi-kok­ku-pan­dud moo­dus­tis. Süs­teem on öko­noom­ne, oma ees­mär­kide saa­vu­ta­mi­sel tu­le­mus­lik, hoolikalt valitud ja tasa­kaa­lus­tatult kon­fi­gu­ree­ri­tud ele­men­ti­de terviklik struk­tuur.

Süsteemi iseloomustab sünergia Ees­märki oma­va, efek­tiivse süs­tee­mi juures on vahest kõige olu­lisem nn süs­teem­ne sü­ner­gia ehk sü­ner­gi­line efekt (sü­ner­gia—või­men­duv koos­toime.) Sü­s­tee­mi ko­gu­efekt on suu­rem kui ele­mentide efek­ti­de sum­ma. Ter­vik on suurem kui osade sum­ma. Või teist­pi­di, süs­teem saa­vu­tab sa­ma tu­le­mu­se öko­noom­se­malt, kui ele­men­did eral­di.

Laused nagu “meil on küll süs­teem, aga see ei toi­mi (ei kasutata, vms)” näi­ta­vad, et mõis­te kasutus on lubamatult lai. Kui organisatsioonis on süs­teem, aga süsteemi kasutata või see ei toimi, kas siis süsteem ikkagi on? Vei­di teravamalt ilmneb selline probleem kvaliteedisüsteemide pu­hul. Et­te­võt­tel võib olla sertifitseeritud ISO kvaliteedisüsteem—pabe­ri­tes, töö­ta­jad kin­nitavad—nii nagu neile on õpetatud—jah, meil on kva­li­tee­disüsteem. Kuid mõnes ette­võt­tes ei suuda praktiliselt keegi seda süs­teemi de­monst­ree­rida, selgitada, mida süsteem annab, mida süsteem üldse tähendab ja kui­das ta toimib.

        Süsteem = Elemendid + Seosed

        Süsteem = Eesmärgid + Koostoimimine (Sünergia)

Need kaks käsitust süsteemist tuleks ühitada—süsteem on nii elemendid, seosed kui ka eesmärgid ja sünergiline koostoime efekt.

Eesti keeles võib süsteemse käsitlusega tutvuda Peeter Lo­rent­si ja Uno Mereste ori­gi­naal­sete raamatute abil. Peeter Lorents, Süsteemse käsitluse alused. EBS Print 2001. Zwass, V. (1992) Systems Concepts. in: Management Information Systems, W. C. Brown Publish­ers, 382-409.

Infosüsteemid on sotsiaalsed süsteemid. Inimene on infosüsteemides tähtis element – kasutaja, arendaja, omaniku rollides. Nn inimteguri olemasolu tõttu ei saa infosüsteeme teha ainult tehnoloogia seaduspärasusi rakendades. Süsteeme kasutavad inimesed, kes lähtuvad sotsiaalsetest (kultuurilistest) normidest.

Ettevõtte info­teh­no­loogiline maas­tik. Ettevõttes on tavaliselt mitmeid infosüsteeme (väikeettevõttes – kaks-kolm, suures ettevõttes – võib olla sadu süsteeme), mis on liidestatud nii üksteisega kui ka ettevõtteväliste süsteemidega. Nii kujuneb süsteemide keerukas kooslus, võrgustik.

Süsteemide tüpoloogia. 1970-ndatest alates on koostatud mitmeid infosüsteemide tüpoloogiaid, kuid tänapäevaks võib neid lugeda vananenuks, sest ilmunud on mitmeid uusi süsteemitüüpe.

Süsteem on sageli osa suuremast süsteemist. In­fo­süs­teemide maas­ti­kus­se kont­septuaalse selguse too­mi­sel tundub produk­tiiv­ne ole­vat nn “süs­tee­mi­de süs­tee­mi” (system of systems) ideoloogia. Infosüsteemi võib ol­la liht­sam uu­ri­da koos teiste et­te­võt­te info­süs­tee­mi­dega.

Lokaalse optimumi oht. Lo­kaal­se optimeerimise oht on info­süs­tee­mi­de juu­res päris suur. Suh­teliselt ***lihtne on teha süs­teem­ne, tõhus la­hendus ühe, kind­lalt piiritletud tööprotsessi või lõigu jaoks. Ette­võt­te kui ter­vi­ku ta­san­dil avalduvad vahest ühed eba­meel­di­vamad info­süs­tee­mide probleemid mit­te nii­võrd ük­sikutes süsteemides eral­di, vaid:

• info­süs­tee­mi­de in­teg­ree­ri­mi­se probleemidena
• töötluses, mi­da oleks saa­nud vältida; nt süs­teemi A väljund on sisendiks süs­tee­mi­le B; kümme kor­da oda­vam oleks ol­nud seada A väljund sel­li­seks,na­gu B vajab; sel­le asemel tuli prog­ram­mee­ri­da süs­tee­mis B suu­res ma­hus, et töö­del­da sis­se­tulnud info va­ja­li­kule kujule
• funkt­si­oo­nide dub­lee­ri­mi­ses
• and­me­te üle­kand­mi­se ja teisenduste prob­lee­mi­des in­fo­süs­tee­mide välja­va­he­ta­mi­sel ja uu­te li­sa­misel.

Seonduv teema on infosüsteemide kaardistamine.

Infosüsteemi rollid tööprotsessi suhtes. In­fosüsteemi funktsioon (või roll) or­ga­ni­sat­sioonis võib olla laiem või kitsam. Tänapäe­val me ei saa reeglina enam öelda, et infosüsteem liht­salt pakub kasutajatele infot. (Siit ilm­neb ka ainult infovajaduste analüüsile põhineva süs­tee­mi­aren­du­ses nõrk koht.) Üks tuntud mudel eristab järgmisi in­fo­süs­tee­mi rolle toetatava tööprotsessi suhtes:

• Pakub infot — infosüsteem teostab arvutusi ning viib nõutud info info­va­ja­jateni.
• Toetab info jagamist — infosüsteem aitab korralda kommunikatsiooni ini­mes­te vahel.
• Struktureerib tööprotsessi — infosüsteem mitte ei toeta (varem olemas ol­nud) tööprotsessi, vaid defineerib tööprotsessi.
• Koordineerib tööprotsesse — infosüsteem aitab optimeerida erinevate töö­protsesside toimimist tervikus (ERP süsteem on hoopis teine kee­ru­kus­tase kui eraldiseisev laoarvestusprogramm).
• Automatiseerib töö — infosüsteem asendab inimese töö.
• Integreerib tööprotsessid — infosüsteem muudab varem eraldiseisnud töö­protsessid üheks tervi­kuks, muutes sellega kogu organisatsiooni toi­mi­mise olemust.

Riihi­maa (2004) leidis Soo­me ettevõtete infosüsteeme uurides kaks huvitavat süs­tee­mi­tüüpi:

• Reliktsüsteemid on vanad info­süs­tee­mid, millest et­te­võte ei ole suut­nud loo­buda ning mis ta­kis­ta­vad uute tehnoloogiliste lahenduste ja süs­tee­mi­de kasutusele­võtmist ettevõttes. Va­na­ne­nud in­fo­süs­teem võib olla arengu pi­du­riks ning on kü­si­tav kas sellise süsteemi majanduslik väär­tus on üldse positiivne.
• Teeseldud süsteemid (fake information systems). Vahel on ettevõte saa­nud riigi arendusfondidest grandi, loodud süsteem (prototüüp) aga ei ole kasutuskõlblik; või on ettevõte ise arendatud süsteemiga jõudnud teatud ummikusse, kuid prob­leeme endale tunnistada ei taheta.

◦ Infokäitluse erisusi mitmesugustes majandusharudes: ehitus, meditsiin, jt.

◦ Näide aktuaalsest, keerukast infosüsteemide liigist: elektrooniline haiguslugu (Electronic Medical Record EMR). Mitmesugused probleemid elektroonilise haigusloo süsteemide juurutamisel.

◦ Infosüsteemide maksumuse suurusjärk. Süsteemiarenduse strateegia sõltuvus organisatsiooni või riigi suurusest.

Tunnetuse otsetee? Kas infokäitlusele on alternatiivi? Kas kõik protsessid, kogu olev ja toimuv on informatsiooniline? Kas kõik toimub läbi info(esituse)? Kristlik seisukoht. Sõna (logos). Martin Heidegger. Kas olemine on infovaba? Tihti on väidetud, et inimene on võimeline tajuma reaalsust vahetult. Jooga, zen ja sufism püüavad vahetut teadvust arendada. Teadvust, mis võtaks vastu kõik signaalid ja muljed, kõrvaldaks selekt­si­oo­ni­prot­ses­si, mudeli ehitamise ja normaalse kategooriasüsteemi. Vt: Aarma, G. (1999) Jooga. Mandala: Pärnu, lk 179. “India filosoof Vivekananda võrdleb inimese harilikku teadvust “joobnud ahviga”. Teadvuses järgneb üks juhus­lik mõte teisele, mõeldes näljale, minevikule, olevikule, tulevikule, kavandades mõnda tegevust — pidevalt ühelt mõttelt teisele.” Aarma, G. (1999) Jooga. Mandala: Pärnu, lk 177 jj.

Riihimaa, J. (2004) Taxo­nomy of information and communication technology system inno­v­ations adopted by small and medium sized enterprizes. Ph.D. Diss. University of Tampere.

Swanson, E. (1994) Information Systems Innovation Among Organizations. Management Science, 40, 9, 1069-1092. – Teooria sellest, kuidas ettevõtted IT-d kasutusele võtavad.

Venkatraman, N. (1994) IT-Enabled Business Transformation: From Automation to Business Scope Redefinition. Harvard Business Review, Winter/1994, 73-87. – Klassikaline artikkel; viis taset IT rakendamisel ettevõttes.

Tehnoloogiate (tarkvarade) hindamine ja valik

help_circleSuur organisatsioon (mitu tuhat töötajat, erinevates allstruktuurides) hangib tööaja planeerimise ja tööaja arvestuse jaoks tarkvara. See on strateegiline otsus, mida eksimise korral on raske tagasi pöörata. Kuidas toimida?

Leiti pakkuja, kes oli nõus oma tarkvara testkasutuseks andma.

Testkasutuse eesmärgiks seati:
- veenduda, et pakkujal on piisava funktsionaalsusega standardne toode/teenus;
- veenduda, et pakkuja toodet on võimalik paigaldada ja hallata tellija keskkonnas (arvestades tellija turvanõudeid);
- veenduda, et pakutav toode on koosvõimeline tellija spetsiifiliste vajaduste jaoks loodud rakendustega; leida allüksuste ülene ühine maksimaalne standardne funktsionaalsus, mida on võimalik katta hangitava tootega.

Testkasutuse käigus selgus, et:
- loobumine kasutusel olevatest senistest lahendustest nõuab töörutiinide ümbertegemist;
- algselt kasutajate püstitatud nõuded on vastuolulised;
- kasutajad kaaluvad loobumist spetsiifilistest nõuetest, et kasutada standardset lahendust.

Küsimus millist tarkvara kasutada on oluline mitmel põhjusel. Hea tarkvaraga võib töö olla 10-20-40% ja enamgi kiirem, mugavam, kvaliteetsem. Hea tarkvara sobib hästi kokku teiste tarkvaradega. Head tarkvara on kerge kasutama õppida, hallata ja kohandada.

Tarkvara valiku otsuseid tehakse suuremas organisatsioonis aastas vähemalt 4-5 tükki aastas. Sageli on nende otsuste mõju oluline.

Näide

Organisatsioonis kasutati aastaid kõrvuti kahte andmebaasisüsteemi: Oracle (tasuline) ja PostgreSQL (vabavara). Iga-aastased Oracle litsentsitasud olid suhteliselt suured. Kulude kokkuhoidmise eesmärgil otsustati üle minna ainult PostgreSQL-le. Otsus oli siiski problemaatiline, sest süsteemiadministraator väitis, et Oracle andmebaasi haldamine on oluliselt kergem ja ähvardas töölt lahkuda.

Tarkvara valikut tehakse praktikas mitmel viisil:

• analüütiline valikuprotsess
• testkasutus
• keegi hakkab kasutama ja kasutus levib.

Analüütiline valikuprotsess võib anda parima tulemuse, kuid ainult siis, kui protsessi läbitegemiseks on piisavalt aega ja kompetentsi. Professionaalne tarkvaravalija [Tate2015] tegutseb metoodiliselt: kaardistab kasutajate vajadused, pöörates tähelepanu erinevate kasutajarühmade esindatusele; vajadused artikuleeritakse selgepiirilisteks nõueteks (Requirements etapp); väljaselgitatud vajadustele lisanduvad hinna- ja tehnoloogilised kaalutlused (nt kokkusobivus teiste tarkvaradega), neist moodustub valikukriteeriumite loetelu; järgmiseks sammuks on turul pakutavate tarkvara-kandidaatide väljaselgitamine ja uurimine.

Artikli TL;TR

[Tate2015] Tate, M. (2015). Off-The-Shelf IT Solutions : A practitioner's guide to selection and procurement. Swindon, GB: BCS, The Chartered Institute for IT.

Metoodiline, võib isegi öelda, et liiga põhjalik protseduur valmistarkvarade valimiseks ettevõttesse. TL;DR: koosta kandidaatide pikk nimekiri (long list), seejärel lühike nimekiri (short list), siis tee otsus

Tarkvara valik on mitmekriteeriumiline otsustusprobleem. Juhtub, et ükski kandidaatidest ei vasta ideaalselt kõigile nõuetele. Siis kasutatakse kandidaatide pingerea koostamiseks mõnda otsustusmeetodit (kaalutud punktikeskmine vms). Tate läheb isegi nii kaugele, et tuletab meelde, et nõuete väljaselgitamiseks korraldatavates tööturbades on otstarbekas teha kohvipause.

Analüütiline valikuprotsess ei anna siiski alati head tulemust.

Esiteks peab organisatsioon olema võimeline süstemaatilist, objektiivset protsessi läbi tegema; kaugeltki alati ei ole see võimekus olemas.

Kõik olulised kriteeriumid tuleb välja selgitada. Kriteeriumite suhtelist tähtsust tuleb hinnata. Hinnangud põhinevad tihti eeldustel. Hinnang, mis on tehtud valedel eeldustel, on parimal juhul kasutu, halvemal juhul - eksitav. Näiteks seatakse tarkvara valikul sageli eesmärgiks infotehnoloogilise keskkonna ühtlustamine, “loomaaia” piiramine. Usutakse, et kui kõik hakkavad kasutama sama töövahendit, siis ühtlustuvad ja korrastuvad ka tööprotsessid ja paraneb kommunikatsioon - rääkimata standardse tarkvara madalamatest hooldus- ja hankimiskuludest. Kahjuks reaalsus nii lihtne ei ole. Universaalset tööriista on raske leida, sageli seda ei olegi. Protsessid võivad olla küll väliselt sarnased, kuid detailitasandil siiski nii spetsiifilised, et nõuavad erinevaid töövahendeid.

Näide

Tarkvaraarendusega ja IT-teenustega tegelevas organisatsioonis otsustati, et kogu teavet hakatakse hoidma Confluence-is. Atlassiani Confluence on hea tarkvara, kuid sobib siiski ainult teatud liiki dokumentatsiooni töötlemiseks.

Teiseks võib süstemaatiline protsess kujuneda töömahukaks ja aeganõudvaks.

Näide

Turul on kümneid, kui mitte sadu märkmete tegemise tarkvarasid. Kes jõuab neid süstemaatiliselt võrrelda?

Näide

Kaks koostööpartnerit otsustasid, et võtavad kumbki kasutusele sama tarkvara. Sobivat tarkvara valiti süstemaatiliselt. Osteti konsultant, kes tegi põhjaliku, mitmekuulise analüüsi. Jõuti juba peaaegu otsuseni, kui viimasel hetkel üks partner loobus, sisuliselt poliitilisel põhjusel.

Kolmandaks ei saa tootekirjelduste põhjal alati õiget pilti tarkvara tegelikust kasutatavusest.

Valikumeetodit võib täiendada tarkvara testkasutusega.

Tarkvara testkasutus on üldlevinud praktika. Tarkvaratootjad pakuvad tarkvara testimiseks mitmesuguseid võimalusi: tasuta katsetamine piiratud perioodi jooksul (Free Trial), piiratud funktsionaalsusega versiooni kasutamine (Free Tier).

Näide

Organisatsioon otsustas, et valib uue tööplaanimise ja tööaja arvestuse tarkvara nii, et laseb kuni neljal IT-firmal paigaldada oma toote testversioon. Töötajatel on vabadus valida, millist kasutada. Valitakse see, mis “jääb ellu”. (Tuli ainult üks IT-firma).

Testkasutuse probleemiks on ajakulu. Siiski tundub, et testimist kasutatakse liiga vähe. Liiga vara seotakse end ühe tarkvaraga - ja liiga kauaks jäädakse seotud ühe tarkvaraga.

Keegi hakkab lihtsalt kasutama. Tarkvara tulek organisatsiooni on innovatsiooniprotsess. Innovatsioon ei ole alati planeeritud ja süstemaatiline. Võib-olla ongi kaootiline, üksikisiku initsiatiivist lähtuv tarkvara kasutuselevõtmise protsess valdav. Keegi on kuulnud heast tarkvarast, toob selle teadmise organisatsiooni, paigaldab tarkvara oma arvutisse või hakkab pilveteenust kasutama.

Näited

1) Asutuses kasutati suurel hulgal .NET tarkvara. Algas sellest, et programmeerija tundis seda. 2) Suures tarkvarasüsteemis programmeeriti üks moodul Ruby-keeles (mis konteksti arvestades ei olnud hea valik). Miks? Programmeerijale meeldis Ruby.

Õige otsustustasand. Juhtkond ei ole õige tasand otsustama, millist vikitarkvara kasutatakse. Samas ei tohiks see otsus tulla ka IT osakonna süsteemiadministraatorilt. Tarkvara valikult peaks lähtuma tarkvara tegelike kasutajate arvamusest, ühitades seda organisatsiooni tervikvaatega.

Tarkvara valides peetakse tavaliselt silmas laiemaid töökorralduslikke ja ärilisi eesmärke. See on õige, kuid seos töö- ja äriprotsessides taotletavate muutustega tuleb ka läbi mõelda.

Huvitav miks, kuid tarkvara valik võtab vahel poliitilise või isegi “usuküsimuse” varjundi. Võib-olla on põhjus selles, et kasutajal tekib sügav emotsionaalne side oma tarkvara. Võib-olla alahinnatakse ümberõppimise psühholoogilist kulu. Võib-olla ka selles, et nii nagu muud tooted, on tarkvara tugevalt bränditud.

Tegelik kasutuselevõtt. Tarkvara valik on ainult eelmäng tegelikule kasutuselevõtule. Tihti libisetakse sellest üle, kuid tegelikult on tarkvara kasutuselevõtmine pikk ja keeruline protsess. Tarkvara kasutuselevõttu mõjutavaid tegureid on palju uuritud ja loodud mitmesuguseid teooriaid. Tuntuim neist on tehnoloogia kasutuselevõtu mudel Technology Acceptance Model, TAM. TAM-st on mitmeid variatsioone. Kriitikud väidavad siiski, et teooria on triviaalne.

Praktikas kuuldu

“Olen aastatega jõudnud järeldusele, et tehnoloogia valik on üleüldse kõige raskem ülesanne, mis IT valdkonnas võib ette tulla. Asjade õige nimetamine on peaaegu lahendamatu probleem, siis tuleb tükk tühja maad ja alles siis tuleb tehnoloogia valiku probleem.” (IT-teenusepakkuja firmajuht)

Praktilised valikumeetodid. Eelöeldust üldistust teha on raske. Tarkvara valikuks ei ole ühte universaalset protsessi. Pretendeerimata ammendavusele võib nimetada kolme teed:

1) Leida usaldatav teabeallikas ja usaldada selle soovitust. Lihtsamate tarkvarade võrdlusi leiab kergesti (vt all), põhjalikumad analüüsid on tasulised (nt Gartner).

Tarkvara

“Teha”-tarkvara. 40 of the Best To-Do Apps for Personal Task Management. Probleem: töödega unustamine, viivitamine ja hilinemine; lahendus: ToDo app (List and Task Manager); Edenemisaruannete (Progress Report) tarkvarasid :

• I Done This
• Weekdone.com
• 14 Free Business Tools to Make Your Startup more Successful in 2017

2) Teha ise läbi metoodiline, analüütiline valikuprotsess.

Näide

Kanban-laua valik. Tarkvaraarendusega tegelev tiim otsib tööde planeerimise ja jälgimise vahendit.

Hindamistabel

3) Osta teadmine sisse, kas tasulise turuülevaate või konsultatsiooniteenuse näol.

Tee ise tööriist

“Build tools for yourself.” – Edmond Lau, Effective Engineer

Väljapaistvaid professionaale eristab see, et nad teevad endale ise tööriistu, kirjutab Lau. Tõepoolest, kui Facebook tahab teha veebiarendust või Google andmeid vahetada, siis kirjutatakse ise veebiraamistik (React) ja andmevahetusprotokoll (Protocol Buffers).